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Abstract 


The Session Peering Provisioning Framework (SPPF) specifies the data 
model and the overall structure to provision Session Establishment 
Data (SED) into Session Data Registries and SIP Service Provider data 
stores. To utilize this framework, one needs a substrate protocol. 
Given that the Simple Object Access Protocol (SOAP) is currently 
widely used for messaging between elements of such provisioning 
systems, this document specifies the usage of SOAP (via HTTPS) as the 
substrate protocol for SPPF. The benefits include leveraging 
prevalent expertise and a higher probability that existing 
provisioning systems will be able to easily migrate to using an SPPF- 
based protocol. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7878. 
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1. Introduction 


SPPF, defined in [RFC7877], is best supported by a transport and 
messaging infrastructure that is connection oriented, is request- 
response oriented, is easily secured, supports propagation through 
firewalls in a standard fashion, and is easily integrated into back- 
office systems. This is due to the fact that the client side of SPPF 
is likely to be integrated with organizations' operational support 
systems that facilitate transactional provisioning of user addresses 
and their associated SED. The server side of SPPF is likely to 
reside in a separate organization's network, resulting in the SPPF 
provisioning transactions traversing the Internet as they are 
propagated from the SPPF client to the SPPF server. Given the 
current state of industry practice and technologies, SOAP and HTTP(S) 
are well suited for this type of environment. This document 
describes the specification for transporting SPPF XML structures, 
using SOAP and HTTP(S) as substrates. 


The specification in this document for transporting SPPF XML 


structures over SOAP and HTTP(S) is primarily comprised of five 
subjects: (1) a description of any applicable SOAP features, (2) any 
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applicable HTTP features, (3) security considerations, (4) (perhaps 
most importantly) the Web Services Description Language (WSDL) 
definition for the SPP Protocol over SOAP, and (5) XML Schema 
Definition (XSD) types that are "substrate" specific. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. SOAP Features and Protocol Layering 


The list of SOAP features that are explicitly used and required for 
SPPP over SOAP are limited. Most SOAP features are not necessary for 
SPPF. SPPP over SOAP primarily uses SOAP simply as a standard 
message-envelope technology. The SOAP message envelope is comprised 
of the SOAP header and body. As described in the SOAP specification 
[SOAPREF], the SOAP header can contain optional, application- 
specific, information about the message. The SOAP body contains the 
SPPF message itself, whose structure is defined by the combination of 
one of the WSDL operations defined in this document and the SPPF XML 
data structures defined in this document and the SPPF document.  SPPF 
does not rely on any data elements in the SOAP header. All relevant 
data elements are defined in the SPPF XML Schema described in 
[RFC7877] and the SPPF WSDL types specification described in 

Section 9 of this document. 


WSDL is a widely standardized and adopted technology for defining the 
top-level structures of the messages that are transported within the 
body of à SOAP message. The WSDL definition for the SPPF SOAP 
messages is defined later in this document, which imports by 
reference the XML data types contained in the SPPF schema. The IANA 
registry where the SPPF schema resides is described in "The IETF XML 
Registry" [RFC3688]. 


There are multiple structural styles that WSDL allows. The best 
practice for this type of application is what is sometimes referred 
to as the "document/literal wrapped style". This style is generally 
regarded as an optimal approach that enhances maintainability, 
comprehension, portability, and, to a certain extent, performance. 
It is characterized by setting the soapAction binding style as 
"document", the soapAction encoding style as "literal", and then 
defining the SOAP messages to simply contain a single data element 
that "wraps" a data structure containing all the required input or 
output data elements. The figure below illustrates this high-level 
technical structure as conceptual layers 3 through 6. 
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4------------- + 
(1) | Transport  |Example: 
| Protocol | TCP, TLS, BEEP, etc. 
4------------- t 
| 
V 
4------------- + 
(2) | Message | Example: 
| Envelope | HTTP, SOAP, None, etc. 
4------------- + 
| 
V 
4-------------- + 
+---- | SOAP |---+ 
|(3) | Operation | | 
Contains a ek terè ELI + Contains 
Example: | 
V submitAddRqst V 
4-------------- t 4------------- + 
| SOAP Reguest | | SOAP Response | 
| Message (4) | Message Example: 
(Operation (Operation spppAdd 
Input) Output) ResponseMsg 
4-------------- t 4------------- + 
| | 
Contains | | Contains 
; ; 
4-------------- t 4--------------- t 
| Wrapped | (5) | Wrapped | Example: 
|Request Object | |Response Object | spppAdd 
e m a + io le + Response 
| | 
Contains Contains 
V V 
4-------------- + 4--------------- t 
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| XML Types | (6) | XML Types | 
4-------------- t 4--------------- t 
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The operations supported by SPPP over SOAP are normatively defined 
later in this document. Each SOAP operation defines a request/input 
message and a response/output message. Each such request and 
response message then contains a single object that wraps the SPPF 
XML data types that comprise the inputs and the outputs, 
respectively, of the SOAP operation. 


SOAP faults are not used by the SPPP over SOAP. All success and 
error responses are specified in Section 7.3 of this document. 
However, if a SOAP fault were to occur, perhaps due to failures in 
the SOAP message handling layer of a SOAP library, the client 
application should capture and handle the fault. Specifics on how to 
handle such SOAP faults, if they should occur, will be specific to 
the chosen SOAP implementation. 


Implementations MUST use SOAP 1.2 [SOAPREF] or higher and MUST 
support SOAP 1.2.  Implementations SHOULD use WSDL 1.1 [WSDLREF] and 
MUST NOT use earlier versions. Use of WSDL versions greater than 1.1 
may introduce interoperability problems with implementations that use 
Peds 


SPPF is a request/reply framework that allows a client application to 
submit provisioning data and query requests to a server. The SPPF 
data structures are designed to be protocol agnostic. Concerns 
regarding encryption, non-repudiation, and authentication are beyond 
the scope of this document. For more details, please refer to 
Section 4 ("Transport Substrate Protocol Requirements") of [RFC7877]. 


As illustrated in the previous diagram, SPPF can be viewed as a set 
of layers that collectively define the structure of an SPPF request 
and response. Layers 1 and 2 represent the transport, envelope, and 
authentication technologies. This document defines layers 3, 4, 5, 
and 6 for SPPP over SOAP. 


1. Layer 1: The transport protocol layer represents the 
communication mechanism between the client and server. SPPF can 
be layered over any substrate protocol that provides a set of 
basic requirements defined in Section 4 of [RFC7877]. 


2. Layer 2: The message-envelope layer is optional but can provide 
features that are above the transport technology layer but below 
the application messaging layer. Technologies such as HTTP and 
SOAP are examples of message-envelope technologies. 


3. Layers 3, 4, 5, and 6: The operation and message layers provide 
an envelope-independent and substrate-independent wrapper for the 
SPPF data model objects that are being acted on (created, 
modified, and queried). 
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4. 


HTTP(S) Features and SPPP over SOAP 


While SOAP is not tied to HTTP(S), for reasons described in the 
Introduction, HTTP(S) is a good choice as the substrate protocol for 
the SPP Protocol SOAP messages. HTTP 1.1 includes the "persistent 
connection" feature, which allows multiple HTTP request/response 
pairs to be transported across a single HTTP connection. This is an 
important performance optimization feature, particularly when the 
connection is an HTTPS connection where the relatively time-consuming 
TLS handshake has occurred. 


Implementations compliant with this document MUST use HTTP 1.1 
[RFC7230] or higher. Also, implementations SHOULD use persistent 
connections. 


Authentication, Integrity, and Confidentiality 


To accomplish authentication, conforming SPPP over SOAP clients and 
servers MUST use HTTP Digest Authentication as defined in [RFC7235]. 


To achieve integrity and privacy, conforming SPPP over SOAP clients 
and servers MUST support TLS as defined in [RFC5246] as the secure 
transport mechanism. Use of TLS MUST follow the recommendations 
contained in [RFC7525] 


Language Identification 


Section 9 of [RFC7877] requires protocols to provide a mechanism to 
transmit language tags together with human-readable messages. When 
conforming SPPP SOAP servers use such tagging, the XML "lang" 
attribute ([W3C.REC-xm1-20081126], Section 2.12) MUST be used. 
Clients MAY use the HTTP "Accept-Language" header field (see 
Section 5.3.5 of [RFC7231]) in order to indicate their language 
preference. 


SPPP SOAP Data Structures 


SPPP over SOAP uses a set of XML-based data structures for all the 
supported operations and any parameters to which those operations are 
applied. As also mentioned earlier in this document, these XML 
structures are envelope independent and substrate independent. Refer 
to "Protocol Operations" (Section 8) of this document for a 
description of all the operations that MUST be supported. 


The following sections describe the definitions of all the XML data 
structures. 
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7.1. Concrete Object Key Types 


Certain operations in SPPF require an object key that uniquely 
identifies the object(s) on which a given operation needs to be 
performed.  SPPF defines the XML structure of any such object key in 
an abstract manner and delegates the concrete representation to any 
conforming substrate protocol. The following subsections define the 
various types of concrete object key types used in various operations 
in SPPP over SOAP. 


7.1.1. Generic Object Key 


Most objects in SPPP over SOAP are uniquely identified by the 
attributes in the generic object key (Refer to "Generic Object Key 
Type", Section 5.2.1 of [RFC7877], for details). The concrete XML 
representation of ObjKeyType is as below: 


«complexType name-"ObjKeyType"» 
«complexContent» 
«extension base="sppfb:ObjKeyType"> 
«sequence» 
«element name="rant" type-"sppfb:OrgIdType"/» 
«element name-"name" type-"sppfb:ObjNameType"/» 
«element name-"type" type-"sppfs:ObjKeyTypeEnum"/» 
«/sequence» 
«/extension» 
«/complexContent» 
«/complexType» 


The ObjKeyType has the data elements as described below: 


o rant: The identifier of the Registrant organization that owns the 
object. 


o name: The character string that contains the name of the object. 


o type: The enumeration value that represents the type of SPPF 
object. For example, both a Destination Group and a SED Group can 
have the same name "TestObj" and be associated with the same 
Registrant ID. Hence, to uniquely identify the object that 
represents a Destination Group with the name "TestObj", the type 
"DestGrp" must be specified when using this concrete ObjKeyType 
structure to identify the Destination Group "TestObj". 
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The object types in SPPP over SOAP MUST adhere to the above 


definition of generic object key and are defined as an enumeration in 
the XML data structure as follows: 


<simpleType name-"ObjKeyTypeEnum"» 
«restriction base="token"> 
«enumeration value-"SedGrp"/» 
«enumeration value-"DestGrp"/» 
«enumeration value-"SedRec"/» 
«enumeration value-"EgrRte"/» 
«/restriction» 
«/simpleType» 


7.1.2. Public Identifier Object Key 


Public Identifier type objects can further be of various sub-types 
like a Telephone Number (TN), Routing Number (RN), TN Prefix, URI, or 
TN Range and cannot be cleanly identified with the attributes in the 
generic ObjKeyType. The definition of PubIdKeyType is as below: 


«complexType name="PubIdKeyType"> 


«complexContent» 

«extension base="sppfb:PubIdKeyType"> 
«sequence» 
«element name="rant" type="sppfb:OrgIdType"/» 
«choice» 


«element name="number" 
type-"sppfb:NumberType"/» 
«element name-"range" 
type=" sppfb:NumberRangeType"/> 
<element name="uri" 
type="anyURI"/> 
</choice> 
</seguence> 
</extension> 
</complexContent> 
</complexType> 


The PubIdKeyType has data elements, as described below: 


o rant: The identifier of the Registrant organization that owns the 
object. 


o number: An element of type NumberType (refer to Section 12 of 
[RFC7877]) that contains the value and type of a number. 


o range: An element of type NumberRangeType (refer to Section 12 of 
[RFC7877]) that contains a range of numbers. 
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o uri: A value that represents a Public Identifier. 


Any instance of PubldKeyType MUST contain exactly one element from 
the following set of elements: "number", "range", "uri". 


7.1.3. SED Group Offer Key 


In addition to the attributes in the generic ObjKeyType, a SED Group 
Offer object is uniquely identified by the organization ID of the 
organization to whom a SED Group has been offered. The definition of 
SedGrpOfferKeyType is as below: 


«complexType name-"SedGrpOfferKeyType"» 
«complexContent» 
«extension base="sppfb:SedGrpOfferKeyType "» 
«sequence» 
«element name="sedGrpKey" type="sppfs:ObjKeyType"/» 
«element name="offeredTo" type="sppfb:OrgIdType"/» 
«/sequence» 
«/extension» 
«/complexContent» 
«/complexType» 


The SedGrpOfferKeyType has the data elements as described below: 


o sedGrpkey: Identifies the SED Group that was offered. 


o offeredTo: The organization ID of the organization that was 
offered the SED Group object identified by the sedGrpkey. 


7.2. Operation Request and Response Structures 


An SPPF client interacts with an SPPF server by sending one or more 
requests to the server and by receiving corresponding responses from 
the server. The basic set of operations that an SPPF client can 
submit to an SPPF server and the semantics of those operations are 
defined in "Framework Operations", Section 7 of [RFC7877]. The 
following subsections describe the XML data structures that are used 
for each of those types of operations for an SPPP over SOAP 
implementation. 


7.2.1. Add Operation Structure 


In order to add (or modify) an object in the Registry, an authorized 
entity can send the spppAddRequest to the Registry. 
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An SPPP over SOAP Add request is wrapped within the «spppAddRequest» 
element while an SPPP over SOAP Add response is wrapped within an 
«spppAddResponse» element. The following sub-sections describe the 
<spppAddRequest> and «spppAddResponse» elements. Refer to Section 10 
for an example of an Add operation on each type of SPPF object. 


7.2.1.1. Add Request 


An SPPP over SOAP Add request definition is contained within the 
generic <spppAddRequest> element. 


«element name="spppAddRequest"> 
«complexType» 
«sequence» 
«element name-"clientTransId" 
type="sppfb:TransIdType" minOccurs="O"/» 
«element name-"minorVer" 
type="sppfb:MinorVerType" minOccurs-"0"/» 
<element name="obj" type="sppfb:BasicObjType" 
maxOccurs-"unbounded"/» 
«/sequence» 
«/complexType» 
«/element» 


The data elements within the «spppAddRequest» element are described 
as follows: 


O clientTransId: Zero or one client-generated transaction ID that, 
within the context of the SPPF client, identifies this request. 
This value can be used at the discretion of the SPPF client to 


track, log, or correlate requests and their responses. The SPPF 
server MUST echo back this value to the client in the 
corresponding response to the incoming request. The SPPF server 


will not check this value for uniqueness. 


o minorVer: Zero or one minor version identifier, as defined in 
Section 7.4. 


o obj: One or more elements of abstract type BasicObjType (defined 
in [RFC7877]). Each element contains all the attributes of an 
SPPF object that the client is requesting the SPPF server to add. 
Refer to Section 3.1 of [RFC7877] for the XML structure of all 
concrete types, for various SPPF objects, that extend from 
abstract BasicObjType and hence are eligible to be passed into 
this element. The elements are processed by the SPPF server in 
the order in which they are included in the request. With respect 
to the handling of error conditions, conforming SPPP SOAP servers 
MUST stop processing BasicObjType elements in the request at the 
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first error and roll back any BasicObjType elements that had 
already been processed for that add request ("stop and roll 
back"). 


7.2.1.2. Add Response 


An SPPP over SOAP add response object is contained within the generic 
«spppAddResponse» element. This response structure is used for all 
types of SPPF objects that are provisioned by the SPPF client. 


«element name="spppAddResponse"> 
«complexType» 
«sequence» 
«element name-"clientTransId" type="sppfb:TransIdType" 
minOccurs-"0"/» 
«element name="serverTransId" type-"sppfb:TransIdType"/» 
«element name-"overallResult" type-"sppfs:ResultCodeType"/» 
«element name-"detailResult" type-"sppfs:ObjResultCodeType" 
minOccurs="O" maxOccurs-"unbounded"/» 
«/sequence» 
«/complexType» 
</element> 


<complexType name="ResultCodeType"> 
<seguence> 
<element name="code" type="int"/> 
<element name="msg" type="string"/> 
</seguence> 
</complexType> 


<complexType name="ObjResultCodeType"> 
<complexContent> 
<extension base="sppfs:ResultCodeType"> 
<seguence> 
<element name="obj" type="sppfb:BasicObjType"/> 
</seguence> 
</extension> 
</complexContent> 
</complexType> 


An «spppAddResponse» contains the elements necessary for the SPPF 
client to precisely determine the overall result of the request, and 
if an error occurs, it provides information about the specific 
object(s) that caused the error. 
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7 


.2 


The data elements within the SPPP over SOAP Add response are 
described as follows: 


o clientTransId: Zero or one client transaction ID. This value is 
simply an echo of the client transaction ID that the SPPF client 
passed into the SPPF update request. When included in the 
request, the SPPF server MUST return it in the corresponding 
response message. 


o serverTransId: Exactly one server transaction ID that identifies 
this request for tracking purposes. This value MUST be unique for 
a given SPPF server. 


o overallResult: Exactly one response code and message pair that 
explicitly identifies the result of the request. See Section 7.3 
for further details. 


o detailResult: An optional response code, response message, and 
BasicObjType (as defined in [RFC7877]) triplet. This element will 
be present only if an object-level error has occurred. It 
indicates the error condition and the exact request object that 
contributed to the error. The response code will reflect the 
exact error. See Section 7.3 for further details. 


.2. Delete Operation Structure 


In order to remove an object from the Registry, an authorized entity 
can send the spppDelRequest into the Registry. An SPPP over SOAP 
Delete request is wrapped within the «spppDelRequest» element while 
an SPPP over SOAP Delete response is wrapped within the generic 
<spppDelResponse> element. The following subsections describe the 
<spppDelReguest> and <spppDelResponse> elements. Refer to Section 10 
for an example of the Delete operation on each type of SPPF object. 
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7.2.2.1. Delete Request 


An SPPP over SOAP Delete request definition is contained within the 
generic <spppDelReguest> element. 


«element name="spppDelRequest"> 

«complexType» 
«sequence» 
<element name-"clientTransId" 
type="sppfb:TransIdType" minOccurs="0"/> 
«element name-"minorVer" 
type-"sppfb:MinorVerType" minOccurs-"0"/» 
<element name-"objKey" type="sppfb:ObjKeyType" 
maxOccurs-"unbounded"/» 
«/sequence» 

«/complexType» 

</element> 


The data elements within the «spppDelRequest» element are described 
as follows: 


o 


clientTransId: Zero or one client-generated transaction ID that, 
within the context of the SPPF client, identifies this request. 
This value can be used at the discretion of the SPPF client to 


track, log, or correlate requests and their responses. The SPPF 
server MUST echo back this value to the client in the 
corresponding response to the incoming request.  SPPF server will 


not check this value for uniqueness. 


minorVer: Zero or one minor version identifier, as defined in 
Section 7.4. 


objKey: One or more elements of abstract type ObjKeyType (as 
defined in [RFC7877]). Each element contains attributes that 
uniquely identify the object that the client is requesting the 
server to delete. Refer to Section 7.1 for a description of all 
concrete object key types, for various SPPF objects, which are 
eligible to be passed into this element. The elements are 
processed by the SPPF server in the order in which they are 
included in the request. With respect to the handling of error 
conditions, conforming SPPP SOAP servers MUST stop processing 
ObjKeyType elements in the request at the first error and roll 
back any ObjKeyType elements that had already been processed for 
that Delete request ("stop and roll back"). 
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7.2.2.2. Delete Response 


An SPPP over SOAP delete response object is contained within the 
generic «sppDeleteResponse» element. This response structure is used 
for a Delete request on all types of SPPF objects that are 
provisioned by the SPPF client. 


«element name=" spppDelResponse"> 
<complexType> 
<seguence> 
«element name-"clientTransId" type="sppfb:TransIdType" 
minOccurs-"0"/» 
«element name="serverTransId" type-"sppfb:TransIdType"/» 
«element name-"overallResult" type-"sppfs:ResultCodeType"/» 
<element name="detailResult" type="sppfs:ObjKeyResultCodeType" 
minOccurs="O" maxOccurs-"unbounded"/» 
«/sequence» 
«/complexType» 
«/element» 


<complexType name="ResultCodeType "» 
«sequence» 
«element name="code" type="int"/» 
«element name="msg" type-"string"/» 
«/sequence» 

«/complexType» 


«complexType name-"ObjKeyResultCodeType"» 
«complexContent» 
«extension base="sppfs:ResultCodeType"> 
«sequence» 
«element name-"objKey" type-"sppfb:ObjKeyType"/» 
«/sequence» 
«/extension» 
«/complexContent» 
«/complexType» 


An «spppDelResponse» contains the elements necessary for the SPPF 
client to precisely determine the overall result of the request, and 
if an error occurs, it provides information about the specific object 
key(s) that caused the error. 
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The data elements within the SPPP over SOAP Delete response are 
described as follows: 


O clientTransId: Zero or one client transaction ID. This value is 
simply an echo of the client transaction ID that the SPPF client 
passed into the SPPF update request. When included in the 
request, the SPPF server MUST return it in the corresponding 
response message. 


o serverTransId: Exactly one server transaction ID that identifies 
this request for tracking purposes. This value MUST be unique for 
a given SPPF server. 


o overallResult: Exactly one response code and message pair that 
explicitly identifies the result of the request. See Section 7.3 
for further details. 


o detailResult: An optional response code, response message, and 
ObjKeyType (as defined in [RFC7877]) triplet. This element will 
be present only if a specific object key level error has occurred. 
It indicates the error condition and the exact request object key 
that contributed to the error. The response code will reflect the 
exact error. See Section 7.3 for further details. 


3. Accept Operation Structure 


In SPPF, a SED Group Offer can be accepted or rejected by, or on 
behalf of, the Registrant to whom the SED Group has been offered 
(refer to Section 3.1 of [RFC7877] for a description of the SED Group 
Offer object). The Accept operation is used to accept such SED Group 
Offers by, or on behalf of, the Registrant. The request structure 
for an SPPP over SOAP Accept operation is wrapped within the 
<spppAcceptRequest> element while an SPPP over SOAP Accept response 


is wrapped within the generic «spppAcceptResponse» element. The 
following subsections describe the <spppAcceptRequest> and 
«spppAcceptResponse» elements. Refer to Section 10 for an example of 


the Accept operation on a SED Group Offer. 
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7.2.3.1. Accept Request Structure 


An SPPP over SOAP Accept request definition is contained within the 
generic «sppAcceptRequest» element. 


«element name="spppAcceptRequest"> 

<complexType> 
<seguence> 
<element name-"clientTransId" 
type="sppfb:TransIdType" minOccurs="0"/> 
<element name="minorVer" 
type="sppfb:MinorVerType" minOccurs="0"/> 
«element name="sedGrpOfferKey" 
type="sppfs:SedGrpOfferKeyType" 
maxOccurs="unbounded" /» 
«/sequence» 

«/complexType» 

«/element» 


The data elements within the «spppAcceptRequest» element are 
described as follows: 


O 


clientTransId: Zero or one client-generated transaction ID that, 
within the context of the SPPF client, identifies this request. 
This value can be used at the discretion of the SPPF client to 


track, log, or correlate requests and their responses. The SPPF 
server MUST echo back this value to the client in the 
corresponding response to the incoming request. The SPPF server 


will not check this value for uniqueness. 


minorVer: Zero or one minor version identifier, as defined in 
Section 7.4. 


sedGrpOfferKey: One or more elements of type SedGrpOfferKeyType 
(as defined in this document). Each element contains attributes 
that uniquely identify a SED Group Offer that the client is 
requesting the server to accept. The elements are processed by 
the SPPF server in the order in which they are included in the 
request. With respect to the handling of error conditions, 
conforming SPPP SOAP servers MUST stop processing 
SedGrpOfferKeyType elements in the request at the first error and 
roll back any SedGrpOfferKeyType elements that had already been 
processed for that Accept request ("stop and roll back"). 
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7.2.3.2. Accept Response 


An SPPP over SOAP accept response structure is contained within the 
generic <sppAcceptResponse> element. This response structure is used 
for an Accept request on a SED Group Offer. 


<element name="spppAcceptResponse"> 
<complexType> 
<sequence> 
<element name-"clientTransId" type="sppfb:TransIdType" 
minOccurs-"0"/» 
«element name="serverTransId" type-"sppfb:TransIdType"/» 
«element name-"overallResult" type="sppfs:ResultCodeType"/> 
«element name="detailResult" 
type=" sppfs: SedGrpOfferKeyResultCodeType" 
minOccurs="0" maxOccurs="unbounded"/> 
</seguence> 
</complexType> 
</element> 


<complexType name="ResultCodeType"> 
<seguence> 
<element name="code" type="int"/> 
<element name="msg" type="string"/> 
</seguence> 

</complexType> 


<complexType name-"SedGrpOfferKeyResultCodeType"» 
<complexContent> 
<extension base="sppfs:ResultCodeType"> 
<seguence> 
<element name="sedGrpOfferKey" type="sppfs:SedGrpOfferKeyType"/> 
</seguence> 
</extension> 
</complexContent> 
</complexType> 


An <spppAcceptResponse> contains the elements necessary for the SPPF 
client to precisely determine the overall result of the reguest, and 
if an error occurs, it provides information about the specific SED 
Group Offer key(s) that caused the error. 
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The data elements within the SPPP over SOAP Accept response are 
described as follows: 


O clientTransId: Zero or one client transaction ID. This value is 
simply an echo of the client transaction ID that the SPPF client 
passed into the SPPF update request. When included in the 
request, the SPPF server MUST return it in the corresponding 
response message. 


o serverTransId: Exactly one server transaction ID that identifies 
this request for tracking purposes. This value MUST be unique for 
a given SPPF server. 


o overallResult: Exactly one response code and message pair that 
explicitly identifies the result of the request. See Section 7.3 
for further details. 


o detailResult: An optional response code, response message, and 
SedGrpOfferKeyType (as defined in this document) triplet. This 
element will be present only if any specific SED Group Offer key 
level error has occurred. It indicates the error condition and 
the exact request SED Group Offer key that contributed to the 
error. The response code will reflect the exact error. See 
Section 7.3 for further details. 


7.2.4. Reject Operation Structure 


In SPPF, a SED Group Offer can be accepted or rejected by, or on 
behalf of, the Registrant to whom the SED Group has been offered 
(refer to "Framework Data Model Objects", Section 6 of [RFC7877] for 
a description of the SED Group Offer object). The Reject operation 
is used to reject such SED Group Offers by, or on behalf of, the 
Registrant. The request structure for an SPPP over SOAP Reject 
operation is wrapped within the «spppRejectRequest» element while an 
SPPP over SOAP Reject response is wrapped within the generic 
«spppRejecResponse» element. The following subsections describe the 
«spppRejectRequest» and <spppRejecResponse> elements. Refer to 
Section 10 for an example of the Reject operation on a SED Group 
Offer. 
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7.2.4.1. Reject Request 


An SPPP over SOAP Reject request definition is contained within the 
generic <spppRejectRequest> element. 


«element name=" spppRejectReguest"> 

<complexType> 
<seguence> 
<element name-"clientTransId" 
type="sppfb:TransIdType" minOccurs="0"/> 
<element name="minorVer" 
type="sppfb:MinorVerType" minOccurs="0"/> 
«element name="sedGrpOfferKey" 
type="sppfs:SedGrpOfferKeyType" 
maxOccurs="unbounded" /» 
«/sequence» 

«/complexType» 

«/element» 


The data elements within the «spppRejectRequest» element are 
described as follows: 


O 


clientTransId: Zero or one client-generated transaction ID that, 
within the context of the SPPF client, identifies this request. 
This value can be used at the discretion of the SPPF client to 


track, log, or correlate requests and their responses. The SPPF 
server MUST echo back this value to the client in the 
corresponding response to the incoming request. The SPPF server 


will not check this value for uniqueness. 


minorVer: Zero or one minor version identifier, as defined in 
Section 7.4. 


sedGrpOfferKey: One or more elements of type SedGrpOfferKeyType 
(as defined in this document). Each element contains attributes 
that uniquely identify a SED Group Offer that the client is 
requesting the server to reject. The elements are processed by 
the SPPF server in the order in which they are included in the 
request. With respect to the handling of error conditions, 
conforming SPPF servers MUST stop processing SedGrpOfferKeyType 
elements in the request at the first error and roll back any 
SedGrpOfferKeyType elements that had already been processed for 
that Reject request ("stop and roll back"). 
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7.2.4.2. Reject Response 


An SPPP over SOAP reject response structure is contained within the 
generic «sppRejectResponse» element. This response structure is used 
for a Reject request on a SED Group Offer. 


<element name="spppRejectResponse"» 
«complexType» 
«sequence» 
«element name-"clientTransId" type="sppfb:TransIdType" 
minOccurs-"0"/» 
«element name="serverTransId" type-"sppfb:TransIdType"/» 
«element name-"overallResult" type="sppfs:ResultCodeType"/> 
«element name="detailResult" 
type=" sppfs: SedGrpOfferKeyResultCodeType" 
minOccurs="0" maxOccurs="unbounded"/> 
</seguence> 
</complexType> 
</element> 


<complexType name="ResultCodeType"> 
<seguence> 
<element name="code" type="int"/> 
<element name="msg" type="string"/> 
</seguence> 

</complexType> 


<complexType name-"SedGrpOfferKeyResultCodeType"» 
<complexContent> 
<extension base="sppfs:ResultCodeType"> 
<seguence> 
<element name="sedGrpOfferKey" type="sppfs:SedGrpOfferKeyType"/> 
</seguence> 
</extension> 
</complexContent> 
</complexType> 


An <spppRejectResponse> contains the elements necessary for the SPPF 
client to precisely determine the overall result of the reguest, and 
if an error occurs, it provides information about the specific SED 
Group Offer key(s) that caused the error. 
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The data elements within the SPPP over SOAP Reject response are 
described as follows: 


o clientTransId: Zero or one client transaction ID. This value is 
simply an echo of the client transaction ID that the SPPF client 
passed into the SPPF update request. When included in the 
request, the SPPF server MUST return it in the corresponding 
response message. 


O serverTransId: Exactly one server transaction ID that identifies 
this request for tracking purposes. This value MUST be unique for 
a given SPPF server. 


o overallResult: Exactly one response code and message pair that 
explicitly identifies the result of the request. See Section 7.3 
for further details. 


o detailResult: An optional response code, response message, and 
SedGrpOfferKeyType (as defined in this document) triplet. This 
element will be present only if any specific SED Group Offer key 
level error has occurred. It indicates the error condition and 
the exact request SED Group Offer key that contributed to the 
error. The response code will reflect the exact error. See 
Section 7.3 for further details. 


5. Batch Operation Structure 


An SPPP over SOAP Batch request XML structure allows the SPPF client 
to send any of the Add, Del, Accept, or Reject operations together in 
one single request. This gives an SPPF client the flexibility to use 
one single request structure to perform more than operations (verbs). 
The batch request structure is wrapped within the «spppBatchRequest» 
element while an SPPF Batch response is wrapped within the 
«spppBatchResponse» element. The following subsections describe the 
<spppBatchReguest> and «spppBatchResponse» elements. Refer to 
Section 10 for an example of a Batch operation. 
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7.2.5.1. Batch Request Structure 


An SPPP over SOAP Batch request definition is contained within the 
generic <spppBatchReguest> element. 


«element name="spppBatchRequest"> 
«complexType» 
«sequence» 
<element name="clientTransId" 
type="sppfb:TransIdType" minOccurs="0"/> 
<element name="minorVer" 
type-"sppfb:MinorVerType" minOccurs="0"/> 
<choice minOccurs="1" maxOccurs="unbounded"> 
«element name-"addObj" type="sppfb:BasicObjType"/> 
«element name-"delObj" type-"sppfb:ObjKeyType"/» 
«element name-"acceptSedGrpOffer" 
type-"sppfs:SedGrpOfferKeyType"/» 
«element name="rejectSedGrpOffer" 
type-"sppfs:SedGrpOfferKeyType"/» 
«/choice» 
«/sequence» 
«/complexType» 
«/element» 


The data elements within the «sppBatchRequest» element are described 
as follows: 


O 


clientTransId: Zero or one client-generated transaction ID that, 
within the context of the SPPF client, identifies this request. 
This value can be used at the discretion of the SPPF client to 


track, log, or correlate requests and their responses. The SPPF 
server MUST echo back this value to the client in the 
corresponding response to the incoming request. The SPPF server 


will not check this value for uniqueness. 


minorVer: Zero or one minor version identifier, as defined in 
Section 7.4. 


addObj: One or more elements of abstract type BasicObjType where 
each element identifies an object that needs to be added. 


delObj: One or more elements of abstract type ObjKeyType where 
each element identifies a key for the object that needs to be 
deleted 


acceptSedGrpOffer: One or more elements of type SedGrpOfferKeyType 
where each element identifies a SED Group Offer that needs to be 
accepted. 
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o rejectSedGrpOffer: One or more elements of type SedGrpOfferKeyType 
where each element identifies a SED Group Offer that needs to be 
rejected. 


With respect to the handling of error conditions, conforming SPPP 
SOAP servers MUST stop processing elements in the request at the 
first error and roll back any elements that had already been 
processed for that Batch request ("stop and roll back"). 


7.2.5.2. Batch Response 


An SPPP over SOAP batch response structure is contained within the 


generic «sppBatchResponse» element. This response structure is used 
for a Batch request that contains many different types of SPPF 
operations. 


«element name="spppBatchResponse"> 
«complexType» 
«sequence» 
<element name="clientTransId" type="sppfb:TransIdType" 
minOccurs="0"/> 
<element name="serverTransId" type-"sppfb:TransIdType"/» 
<element name="overallResult" type="sppfs:ResultCodeType"/> 
<choice minOccurs="0" maxOccurs="unbounded"> 
<element name="addResult" 
type-2"sppfs:ObjResultCodeType"/» 
«element name="delResult" 
type="sppfs:ObjKeyResultCodeType"/» 
«element name="acceptResult" 
type-"sppfs:SedGrpOfferKeyResultCodeType"/» 
«element name="rejectResult" 
type=" sppfs: SedGrpOfferKeyResultCodeType"/> 
</choice> 
</seguence> 
</complexType> 
</element> 


An <spppBatchResponse> contains the elements necessary for an SPPF 
client to precisely determine the overall result of various 
operations in the reguest, and if an error occurs, it provides 
information about the specific objects or keys in the request that 
caused the error. 
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The data elements within the SPPP over SOAP Batch response are 
described as follows: 


O clientTransId: Zero or one client transaction ID. This value is 
simply an echo of the client transaction ID that the SPPF client 
passed into the SPPF update request. When included in the 
request, the SPPF server MUST return it in the corresponding 
response message. 


o serverTransId: Exactly one server transaction ID that identifies 
this request for tracking purposes. This value MUST be unique for 
a given SPPF server. 


o overallResult: Exactly one response code and message pair that 
explicitly identifies the result of the request. See Section 7.3 
for further details. 


o addResult: One or more elements of type ObjResultCodeType where 
each element identifies the result code, result message, and the 
Specific object to which the result relates. 


o delResult: One or more elements of type ObjKeyResultCodeType where 
each element identifies the result code, result message, and the 
Specific object key to which the result relates. 


o acceptResult: One or more elements of type 
SedGrpOfferKeyResultCodeType where each element identifies the 
result code, result message, and the specific SED Group Offer key 
to which the result relates. 


o rejectResult: One or more elements of type 
SedGrpOfferKeyResultCodeType where each element identifies the 
result code, result message, and the specific SED Group Offer key 
to which the result relates. 


7.2.6. Get Operation Structure 


In order to query the details of an object from the Registry, an 
authorized entity can send the spppGetRequest to the Registry with a 
GetRqstType XML data structure containing one or more object keys 
that uniquely identify the object whose details are being queried. 
The following subsections describe the <spppGetRequest> and 
<spppGetResponse> elements. Refer to Section 10 for an example of 
the SPPP over SOAP Get operation on each type of SPPF object. 
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7.2.6.1. Get Request 


The request structure for an SPPP over SOAP Get operation is 
contained within the generic «spppGetRequest» element: 


«element name="spppGetRequest"> 
<complexType> 
<seguence> 
<element name="minorVer" 
type="sppfb:MinorVerType" minOccurs="0"/> 
<element name="objKey" 
type=" sppfb:ObjKeyType" 
maxOccurs="unbounded" /> 
</seguence> 
</complexType> 
</element> 


The data elements within the «spppGetRequest» element are described 
as follows: 


o minorVer: Zero or one minor version identifier, as defined in 
Section 7.4. 


o objKey: One or more elements of abstract type ObjKeyType (as 
defined in [RFC7877]). Each element contains attributes that 
uniquely identify the object that the client is requesting the 
server to query. Refer to Section 7.1 of this document for a 
description of all concrete object key types, for various SPPF 
objects, which are eligible to be passed into this element. 


7.2.6.2. Get Response 


The SPPP over SOAP Get response is wrapped within the generic 
«spppGetResponse» element, as described in Section 7.2.8. 


7.2.7. Get SED Group Offers Operation Structure 


In addition to the ability to query the details of one or more SED 
Group Offers using a SED Group Offer key in the spppGetRequest, this 
operation also provides an additional, more flexible, structure to 
query for SED Group Offer objects. This additional structure is 
contained within the «getSedGrpOffersRequest» element while the 
response is wrapped within the generic «spppGetResponse» element. 
The following subsections describe the «getSedGrpOffersRequest» and 
<spppGetResponse> elements. 
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7.2.7.1. Get SED Group Offers Request 


Using the details passed into this structure, the server will attempt 
to find SED Group Offer objects that satisfy all the criteria passed 
into the request. If no criteria are passed in, then the SPPF server 
will return the list of SED Group Offer objects that belong to the 
Registrant. If there are no matching SED Group Offers found, then an 
empty result set will be returned. 


«element name="getSedGrpOffersRequest"» 
«complexType» 
«sequence» 
«element name="minorVer" type="sppfb:MinorVerType" 
minOccurs-"0"/» 
«element name="offeredBy" type="sppfb:OrgIdType" 
minOccurs="O" maxOccurs-"unbounded"/» 
«element name="offeredTo" type="sppfb:OrgIdType" 
minOccurs="O" maxOccurs-"unbounded"/» 
«element name="status" type="sppfb:SedGrpOfferStatusType" 
minOccurs-"0"/» 
<element name="sedGrpOfferKey" type="sppfs:SedGrpOfferKeyType" 
minOccurs="O" maxOccurs-"unbounded"/» 
«/sequence» 
«/complexType» 
</element> 


The data elements within the <getSedGrpOffersReguest> element are 
described as follows: 


o minorVer: Zero or one minor version identifier, as defined in 
Section 7.4. 


o offeredBy: Zero or more organization IDs. Only offers that are 
offered to the organization IDs in this list should be included in 
the result set. The result set is also subject to other guery 


criteria in the request. 


o offeredTo: Zero or more organization IDs. Only offers that are 
offered by the organization IDs in this list should be included in 
the result set. The result set is also subject to other query 


criteria in the request. 


o status: The status of the offer, offered or accepted. Only offers 
in the specified status should be included in the result set. If 
this element is not present, then the status of the offer should 
not be considered in the query. The result set is also subject to 
other query criteria in the request. 
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o sedGrpOfferKey: Zero or more SED Group Offer keys. Only offers 
having one of these keys should be included in the result set. 
The result set is also subject to other query criteria in the 
request. 


7.2.7.2. Get SED Group Offers Response 
The spppGetResponse element is described in Section 7.2.8. 
7.2.8. Generic Query Response 


An SPPP over SOAP query response object is contained within the 
generic «spppGetResponse» element. 


«element name="spppGetResponse"> 

<complexType> 
<seguence> 
<element name="overallResult" 
type="sppfs:ResultCodeType"/> 
<element name-"resultObj" 
type="sppfb:BasicObjType" 
minOccurs="O" maxOccurs-"unbounded"/» 
«/sequence» 

«/complexType» 

«/element» 


An «spppGetResponse» contains the elements necessary for the SPPF 
client to precisely determine the overall result of the query and 
details of any SPPF objects that matched the criteria in the request. 


The data elements within the SPPP over SOAP query response are 
described as follows: 


o overallResult: Exactly one response code and message pair that 
explicitly identifies the result of the request. See Section 7.3 
for further details. 


o resultObj: The set of zero or more objects that matched the query 
criteria. If no objects matched the query criteria, then the 
result object(s) MUST be empty and the overallResult value MUST 
indicate success (if no matches are found for the query criteria, 
the response is considered a success). 
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7.2.9. Get Server Details Operation Structure 


In order to query certain details of the SPPF server, such as the 
SPPF server's status and the major/minor version supported by the 
server, the Server Details operation structure SHOULD be used. This 
structure is contained within the <spppServerStatusRequest> element 
whereas an SPPF server status response is wrapped within the 


«spppServerStatusResponse» element. The following subsections 
describe the <spppServerStatusRequest> and <spppServerStatusResponse> 
elements. 


7.2.9.1. Get Server Details Request 


An SPPP over SOAP server details request structure is represented in 
the «spppServerStatusRequest» element as follows: 


«element name="spppServerStatusRequest"> 
«complexType» 
«sequence» 
«element name-"minorVer" 
type="sppfb:MinorVerType" minOccurs-"0"/» 
«/sequence» 
«/complexType» 
</element> 


The data elements within the «spppServerStatusRequest» element are 
described as follows: 


o minorVer: Zero or one minor version identifier, as defined in 
Section 7.4. 


7.2.9.2. Get Server Details Response 


An SPPP over SOAP server details response structure is contained 
within the generic «spppServerStatusResponse» element. 


«element name="spppServerStatusResponse"» 
«complexType» 
«sequence» 
«element name-"overallResult" type="sppfs:ResultCodeType"/> 
«element name-"svcMenu" type-"sppfb:SvcMenuType"/» 
«/sequence» 
«/complexType» 
</element> 
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The data elements within the «spppServerStatusResponse» element are 
described as follows: 


o 


overallResult: Exactly one response code and message pair that 
explicitly identifies the result of the request. See Section 7.3 
for further details. 


svcMenu: Exactly one element of type SvcMenuType that, in turn, 
contains the elements to return the server status, the major and 
minor versions of SPPP over SOAP supported by the SPPF server 
(refer to Section 12 of [RFC7877] for the definition of 
SvcMenuType). 


Response Codes and Messages 


This section contains the listing of response codes and their 


corresponding human-readable text. These response codes are in 
conformance with the response types defined in Section 5.3 of 
[RFC7877]. 


The response code numbering scheme generally adheres to the theory 
formalized in Section 4.2.1 of [RFC5321]: 


O 


The first digit of the response code can only be 1 or 2: 1 ša 
positive result, and 2 = a negative result. 


The second digit of the response code indicates the category: 0 = 
Protocol Syntax, 1 = Implementation Specific Business Rule, 2 = 
Security, and 3 = Server System. 


The third and fourth digits of the response code indicate the 
individual message event within the category defined by the first 
two digits. 


The response codes are also categorized as to whether they are 
overall response codes that may only be returned in the overallResult 
data element in SPPF responses or object-level response codes that 
may only be returned in the detailResult element of the SPPF 
responses. 


Cartwright, et al. Standards Track [Page 30] 


RFC 7878 SPP Protocol over SOAP August 2016 


qose A e re e egentes ene kasa ed SS SS + 
| Result | Result Message | Overall or Object Level 
| Code | | | 
Ho 4+-------------------------- $ O O T E KE RE + 
| 1000 | Request succeeded | Overall Response Code 
| 2000 | Request syntax invalid | Overall Response Code | 
| 2001 | Request too large | Overall Response Code 
| | MaxSupported: [Maximum | 

| requests supported] | 
| 2002 Version not supported Overall Response Code 
| 2100 | Command invalid | Overall Response Code 
| 2300 | System temporarily | Overall Response Code | 
| | unavailable | | 
| 2301 | Unexpected internal | Overall Response Code | 
| | system or server error | 
| 2101 | Attribute value invalid | Object-Level Response Code | 

AttrName: [AttributeName] 
| | AttrVal:[AttributeValue] | 
| 2102 | Object does not exist | Object-Level Response Code | 
| | AttrName: [AttributeName] | 
| | AttrVal:[AttributeValue] | 
2103 | Object status or | Object-Level Response Code 
ownership does not allow 

| | for operation | | 
| | AttrName: [AttributeName] | 
| | AttrVal:[AttributeValue] | 
Foss tit e op one FESS Sane n ii eten + 


Table 1: Response Code Numbering Scheme and Messages 


The response message for response code 2001 is "parameterized" with 
the following parameter: "[Maximum requests supported]". When the 
request is too large, this parameter MUST be used to indicate the 
maximum number of requests supported by the server in a single 
protocol operation. 


Response code 2000 SHOULD be used when the XML Schema validation of 
requests fails. 


Each of the object-level response messages are "parameterized" with 
the following parameters: "AttributeName" and "AttributeValue". 


For example, if an SPPF client sends a request to delete a 
Destination Group with a name "TestDG", and it does not already 
exist, then the error message returned should be: "Attribute value 
invalid.  AttrName:dgName AttrVal:TestDG". 
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The use of these parameters MUST adhere to the rules defined in 
Section 5.3 of [RFC7877]. 


7.4. Minor Version Identifier 
The minor version identifier element is defined as follows: 


o minorVer: Zero or one minor version identifier, indicating the 
minor version of the SPPP over SOAP API that the client is 
attempting to use. This is used in conjunction with the major 
version identifier in the XML Namespace to identify the version of 
SPPP over SOAP that the client is using. If the element is not 
present, the server assumes that the client is using the latest 
minor version of SPPP over SOAP supported by the SPPF server for 
the given major version. The versions of SPPP over SOAP supported 
by a given SPPF server can be retrieved by the client using this 
same spppServerStatusRequest without passing in the minorVer 
element. 


8. Protocol Operations 


Refer to Section 7 of [RFC7877] for a description of all SPPF 
operations and any necessary semantics that MUST be adhered to in 
order to conform with SPPF. 


9. SPPP over SOAP WSDL Definition 


The SPPP over SOAP WSDL and data types are defined below. The WSDL 
design approach is commonly referred to as "Generic WSDL". It is 
generic in the sense that there is not a specific WSDL operation 
defined for each object type that is supported by the SPPF protocol. 
There is a single WSDL structure for each type of SPPF operation. 
Each such WSDL structure contains exactly one input structure and one 
output structure that wraps any data elements that are part of the 
incoming request and the outgoing response, respectively. The 
spppSOAPBinding in the WSDL defines the binding style as "document" 
and the encoding as "literal". It is this combination of "wrapped" 
input and output data structures, "document" binding style, and 
"literal" encoding that characterize the Document Literal Wrapped 
style of WSDL specifications. 


Notes: The following WSDL has been formatted (e.g., tabs, spaces) to 
meet IETF requirements.  Deployments MUST replace 
"REPLACE WITH ACTUAL URL" in the WSDL below with the URI of the SPPF 
server instance. 
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«?xml version="1.0" encoding-"UTF-8"?» 
«wsdl:definitions xmlns:wsdl-"http://schemas.xmlsoap.org/wsdl/" 
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:sppfb="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:sppfs="urn:ietf:params:xml:ns:sppf:soap:1" 
targetNamespace="urn:ietf:params:xml:ns:sppf:soap:1"> 
<wsdl :types> 
«xsd:schema xmlns="http://www.w3.org/2001/XMLSchema" 
xmlns:sppfs-"urn:ietf:params:xml:ns:sppf:soap:1" 
targetNamespace="urn:ietf:params:xml:ns:sppf:soap:1"> 
<annotation> 
<documentation> 
---- Import base schema ---- 
«/documentation» 
«/annotation» 
«import namespace="urn:ietf:params:xml:ns:sppf:base:1" 
schemaLocation="sppfbase.xsd"/> 
<annotation> 
<documentation> 
---- Key type(s) extended 
from base schema. ---- 
«/documentation» 
«/annotation» 
<complexType name="ObjKeyType"> 
<complexContent> 
«extension base="sppfb:ObjKeyType"> 
<seguence> 
«element name="rant" type-"sppfb:OrgIdType"/» 
«element name-"name" type-"sppfb:ObjNameType"/» 
«element name-"type" type-"sppfs:ObjKeyTypeEnum"/» 
«/sequence» 
«/extension» 
«/complexContent» 
«/complexType» 
«simpleType name-"ObjKeyTypeEnum"» 
«restriction base="token"» 
«enumeration value-"SedGrp"/» 
«enumeration value-"DestGrp"/» 
«enumeration value="SedRec"/> 
<enumeration value-"EgrRte"/» 
«/restriction» 
«/simpleType» 


«complexType name-"SedGrpOfferKeyType"» 
«complexContent» 
«extension base="sppfb:SedGrpOfferKeyType "» 
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«sequence» 
«element name="sedGrpKey" 
type-"sppfs:ObjKeyType"/» 
«element name-"offeredTo" 
type-"sppfb:OrgIdType"/» 
«/sequence» 
«/extension» 
«/complexContent» 
«/complexType» 


«complexType name="PubIdKeyType"> 


«complexContent» 

«extension base="sppfb:PubIdKeyType"> 
«sequence» 
«element name="rant" type-"sppfb:OrgIdType"/» 
«choice» 


«element name="number" 
type-"sppfb:NumberType"/» 
«element name-"range" 
type=" sppfb:NumberRangeType"/> 
</choice> 
</seguence> 
</extension> 
</complexContent> 
</complexType> 


<annotation> 
<documentation> 
---- Generic Request and 
Response Definitions ---- 
«/documentation» 
«/annotation» 
«element name="spppAddRequest"> 
«complexType» 
«sequence» 
<element name-"clientTransId" 
type="sppfb:TransIdType" minOccurs="O"/» 
«element name-"minorVer" 
type-"sppfb:MinorVerType" minOccurs-"0"/» 
<element name="obj" type="sppfb:BasicObjType" 
maxOccurs="unbounded" /» 
«/sequence» 
«/complexType» 
</element> 
«element name="spppDelRequest"> 
<complexType> 
<seguence> 
«element name-"clientTransId" 
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type="sppfb:TransIdType" minOccurs="O"/» 
«element name-"minorVer" 
type-"sppfb:MinorVerType" minOccurs-"0"/» 
«element name="objKey" 
type="sppfb:ObjKeyType" maxOccurs-"unbounded"/» 
«/sequence» 
«/complexType» 
</element> 
«element name="spppAcceptRequest"> 
<complexType> 
<seguence> 
«element name-"clientTransId" 
type="sppfb:TransIdType" minOccurs="O"/» 
«element name-"minorVer" 
type-"sppfb:MinorVerType" minOccurs-"0"/» 
«element name="sedGrpOfferKey" 
type="sppfs:SedGrpOfferKeyType" 
maxOccurs="unbounded" /> 
</seguence> 
</complexType> 
</element> 
<element name=" spppRejectReguest"> 
<complexType> 
<seguence> 
«element name-"clientTransId" 
type="sppfb:TransIdType" minOccurs="O"/» 
«element name-"minorVer" 
type="sppfb:MinorVerType" minOccurs-"0"/» 
«element name="sedGrpOfferKey" 
type="sppfs:SedGrpOfferKeyType" 
maxOccurs="unbounded" /> 
</seguence> 
</complexType> 
</element> 
«element name="spppGetRequest"> 
<complexType> 
<seguence> 
<element name="minorVer" 
type="sppfb:MinorVerType" minOccurs="0"/> 
<element name="objKey" 
type=" sppfb:ObjKeyType" 
maxOccurs="unbounded" /> 
</seguence> 
</complexType> 
</element> 
<element name=" spppBat chReguest"> 
<complexType> 
<seguence> 
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«element name-"clientTransId" 
type="sppfb:TransIdType" minOccurs="O"/» 
«element name-"minorVer" 
type-"sppfb:MinorVerType" minOccurs-"0"/» 
«choice minOccurs="1" maxOccurs="unbounded"» 
«element name-"addObj" type-"sppfb:BasicObjType"/» 
«element name-"delObj" type-"sppfb:ObjKeyType"/» 
«element name-"acceptSedGrpOffer" 
type-"sppfs:SedGrpOfferKeyType"/» 
«element name="rejectSedGrpOffer" 
type-"sppfs:SedGrpOfferKeyType"/» 
«/choice» 
«/sequence» 
«/complexType» 
«/element» 
«element name="spppServerStatusRequest"> 
«complexType» 
«sequence» 
«element name-"minorVer" 
type-"sppfb:MinorVerType" minOccurs-"0"/» 
«/sequence» 
«/complexType» 
«/element» 
«element name="getSedGrpOffersRequest"» 
«complexType» 
«sequence» 
«element name-"minorVer" 
type-"sppfb:MinorVerType" minOccurs-"0"/» 
«element name-"offeredBy" 
type="sppfb:OrgIdType" minOccurs="0" 
maxOccurs-"unbounded"/» 
«element name="offeredTo" type="sppfb:OrgIdType" 
minOccurs="O" maxOccurs="unbounded"/> 
«element name="status" 
type="sppfb:SedGrpOfferStatusType" minOccurs="0"/> 
<element name=" sedGrpOfferKey" 
type="sppfs:SedGrpOfferKeyType" 
minOccurs="O" maxOccurs-"unbounded"/» 
«/sequence» 
«/complexType» 
«/element» 
«element name="spppAddResponse"> 
«complexType» 
«sequence» 
<element name="clientTransId" 
type="sppfb:TransIdType" minOccurs="0"/> 
<element name="serverTransld" 
type="sppfb:TransIdType"/> 
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«element name="overallResult" 
type="sppfs:ResultCodeType"/> 
<element name="detailResult" 
type=" sppfs:ObjResultCodeType" 
minOccurs="0" maxOccurs="unbounded"/> 
</seguence> 
</complexType> 
</element> 
«element name=" spppDelResponse"> 
<complexType> 
<seguence> 
«element name-"clientTransId" 
type="sppfb:TransIdType" minOccurs="0"/> 
<element name="serverTransld" 
type="sppfb:TransIdType"/> 
<element name="overallResult" 
type="sppfs:ResultCodeType"/> 
<element name="detailResult" 
type="sppfs:ObjKeyResultCodeType" 
minOccurs="O" maxOccurs-"unbounded"/» 
«/sequence» 
«/complexType» 
«/element» 
«element name="spppAcceptResponse"» 
«complexType» 
«sequence» 
«element name-"clientTransId" 
type-"sppfb:TransIdType" minOccurs="0"/> 
«element name="serverTransld" 
type="sppfb:TransIdType"/> 
<element name="overallResult" 
type="sppfs:ResultCodeType"/> 
<element name="detailResult" 
type=" sppfs: SedGrpOfferKeyResultCodeType" 
minOccurs="0" maxOccurs="unbounded"/> 
</seguence> 
</complexType> 
</element> 
<element name=" spppRejectResponse"> 
<complexType> 
<seguence> 
<element name-"clientTransId" 
type-"sppfb:TransIdType" minOccurs="0"/> 
«element name="serverTransld" 
type="sppfb:TransIdType"/» 
«element name="overallResult" 
type="sppfs:ResultCodeType"/> 
<element name="detailResult" 
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type=" sppfs: SedGrpOfferKeyResultCodeType" 
minOccurs="0" maxOccurs="unbounded"/> 
</seguence> 
</complexType> 
</element> 
<element name=" spppBat chResponse"> 
<complexType> 
<seguence> 
<element name-"clientTransId" 
type="sppfb:TransIdType" minOccurs="O"/» 
«element name="serverTransld" 
type="sppfb:TransIdType"/» 
«element name="overallResult" 
type="sppfs:ResultCodeType "/» 
«choice minOccurs="O" maxOccurs="unbounded"» 
«element name="addResult" 
type="sppfs:ObjResultCodeType"/» 
«element name="delResult" 
type="sppfs:ObjKeyResultCodeType"/» 
«element name="acceptResult" 
type-"sppfs:SedGrpOfferKeyResultCodeType"/» 
«element name="rejectResult" 
type-"sppfs:SedGrpOfferKeyResultCodeType"/» 
«/choice» 
«/sequence» 
«/complexType» 
</element> 
«element name="spppGetResponse"> 
<complexType> 
<seguence> 
<element name="overallResult" 
type="sppfs:ResultCodeType"/> 
<element name="resultObj" 
type=" sppfb:BasicObjType" 
minOccurs="0" maxOccurs="unbounded"/> 
</seguence> 
</complexType> 
</element> 
«element name="spppServerStatusResponse"» 
«complexType» 
«sequence» 
«element name="overallResult" 
type="sppfs:ResultCodeType"/> 
<element name="svcMenu" 
type="sppfb:SvcMenuType"/> 
</sequence> 
</complexType> 
</element> 
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«annotation» 
«documentation» 
---- Operation 
Definitions --- 
«/documentation» 
«/annotation» 


<complexType name="ResultCodeType "» 


«sequence» 


«element name="code" type-"sppfs:ResultCodeValType"/» 
«element name-"msg" type-"sppfs:MsgType"/» 


«/sequence» 
«/complexType» 


<simpleType name="ResultCodeValType"> 
<restriction base="unsignedShort"> 


<enumeration 
<enumeration 
<enumeration 
<enumeration 
<enumeration 
<enumeration 
<enumeration 
<enumeration 
<enumeration 
<enumeration 
</restriction> 
</simpleType> 


<simpleType name= 
<restriction ba 
<minLength val 
<maxLength val 
</restriction> 

</simpleType> 


<complexType name-"ObjResultCodeType"» 


<complexContent> 


«extension base="sppfs:ResultCodeType"> 


<sequence> 


«element name-"obj" type-"sppfb:BasicObjType"/» 


«/sequence» 

«/extension» 
«/complexContent 

«/complexType» 


<complexType name="ObjKeyResultCodeType"> 


<complexContent> 


<extension base="sppfs:ResultCodeType"> 


<seguence> 
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value="1000"/> 
value="2000"/> 
value="2001"/> 
value="2002"/> 
value="2100"/> 
value="2101"/> 
value="2102"/> 
value="2103"/> 
value="2300"/> 
value="2301"/> 


"MsgType"> 
se="token"> 
ue="3" /> 
ue="255"/> 
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«element name-"objKey" type-"sppfb:ObjKeyType"/» 
«/sequence» 
«/extension» 
«/complexContent» 
«/complexType» 
<complexType name="SedGrpOfferKeyResultCodeType "» 
«complexContent» 
«extension base="sppfs:ResultCodeType"> 
«sequence» 
«element name="sedGrpOfferKey" 
type-"sppfs:SedGrpOfferKeyType"/» 
«/sequence» 
«/extension» 
«/complexContent» 
«/complexType» 
«/xsd:schema» 
«/wsdl:types» 
«wsdl:message name=" spppAddReguestMsg"> 
«wsdl:part name="rgst" element="sppfs:spppAddReguest"/> 
«/wsdl:message» 
«wsdl:message name=" spppDelReguestMsg"> 
«wsdl:part name="rgst" element="sppfs:spppDelReguest"/> 
«/wsdl:message» 
«wsdl:message name="spppAcceptRequestMsg"> 
«wsdl:part name="rgst" element="sppfs:spppAcceptReguest"/> 
«/wsdl:message» 
«wsdl:message name="spppRejectRequestMsg"» 
«wsdl:part name="rgst" element="sppfs:spppRejectReguest"/> 
«/wsdl:message» 
«wsdl:message name="spppBatchRequestMsg"> 
«wsdl:part name="rgst" element="sppfs:spppBatchReguest"/> 
«/wsdl:message» 
«wsdl:message name=" spppGet ReguestMsg"> 
«wsdl:part name="rgst" element="sppfs:spppGetReguest"/> 
«/wsdl:message» 
«wsdl:message name-"spppGetSedGrpOffersRequestMsg"» 
«wsdl:part name="rgst" element="sppfs:getSedGrpOffersRequest"/» 
«/wsdl:message» 
«wsdl:message name=" spppAddResponseMsg"> 
«wsdl:part name="rspns" element="sppfs:spppAddResponse"/> 
«/wsdl:message» 
«wsdl:message name=" spppDelResponseMsg"> 
«wsdl:part name="rspns" element="sppfs:spppDelResponse"/> 
«/wsdl:message» 
«wsdl:message name="spppAcceptResponseMsg"> 
«wsdl:part name="rspns" element="sppfs:spppAcceptResponse"/> 
«/wsdl:message» 
«wsdl:message name="spppRejectResponseMsg"» 
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part name-"rspns" element-"sppfs:spppRejectResponse"/» 
message» 

message name="spppBatchResponseMsg"> 

part name="rspns" element="sppfs:spppBatchResponse"/> 
message> 


«wsdl:message name=" spppGet ResponseMsg"> 


«wsdl: 
«/wsdl: 


part name-"rspns" element-"sppfs:spppGetResponse"/» 
message» 


«wsdl:message name-"spppServerStatusRequestMsg"» 


«wsdl: 
«/wsdl: 


part name-"rqst" element="sppfs:spppServerStatusRequest"/> 
message» 


«wsdl:message name=" sppp$erverStatusResponseMsg"> 


«wsdl: 
«/wsdl: 


part name="rspns" element="sppfs:spppServerStatusResponse"/» 
message» 


«wsdl:portType name="spppPortType "» 


«wsdl: 


operation name="submitAddRgst"> 


«wsdl:input message-"sppfs:spppAddRequestMsg"/» 
«wsdl:output message-"sppfs:spppAddResponseMsg"/» 
«/wsdl:operation» 


«wsdl: 


operation name="submitDelRgst"> 


«wsdl:input message="sppfs:spppDelReguestMsg"/> 
«wsdl:output message-"sppfs:spppDelResponseMsg"/» 
«/wsdl:operation» 


«wsdl: 


operation name="submitAcceptRgst"> 


«wsdl:input message-"sppfs:spppAcceptRequestMsg"/» 
«wsdl:output message-"sppfs:spppAcceptResponseMsg"/» 
«/wsdl:operation» 


«wsdl: 


operation name="submitRejectRgst"> 


«wsdl:input message-"sppfs:spppRejectRequestMsg"/» 
«wsdl:output message-"sppfs:spppRejectResponseMsg"/» 
«/wsdl:operation» 


«wsdl: 


operation name="submitBatchRqst '» 


«wsdl:input message-"sppfs:spppBatchRequestMsg"/» 
«wsdl:output message-"sppfs:spppBatchResponseMsg"/» 
«/wsdl:operation» 


«wsdl: 


operation name="submitGetRgst"> 


«wsdl:input message-"sppfs:spppGetRequestMsg"/» 
«wsdl:output message-"sppfs:spppGetResponseMsg"/» 
«/wsdl:operation» 


«wsdl: 


operation name="submitGetSedGrpOffersRqst"» 


«wsdl:input message-"sppfs:spppGetSedGrpOffersRequestMsg"/» 
«wsdl:output message-"sppfs:spppGetResponseMsg"/» 
«/wsdl:operation» 


«wsdl: 


operation name-"submitServerStatusRqst"» 


«wsdl:input message-"sppfs:spppServerStatusRequestMsg"/» 
«wsdl:output message-"sppfs:spppServerStatusResponseMsg"/» 
«/wsdl:operation» 


«/wsdl: 
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«wsdl:binding name="spppSoapBinding" type-"sppfs:spppPortType"» 
«soap:binding style="document" 
transport-"http://schemas.xmlsoap.org/soap/http"/» 
«wsdl:operation name="submitAddRqst"> 

«soap:operation soapAction-"submitAddRqst" style-"document"/» 
«wsdl:input» 
«soap:body use-"literal"/» 
«/wsdl:input» 
«wsdl:output» 
«soap:body use-"literal"/» 
«/wsdl:output» 
«/wsdl:operation» 
«wsdl:operation name="submitDelRgst"> 
«soap:operation soapAction-"submitDelRqst" style-"document"/» 
«wsdl:input» 
«soap:body use-"literal"/» 
«/wsdl:input» 
«wsdl:output» 
«soap:body use-"literal"/» 
«/wsdl:output» 
«/wsdl:operation» 
«wsdl:operation name=" submitAcceptRgst"> 
«soap:operation soapAction-"submitAcceptRqst" style-"document"/» 
«wsdl:input» 
«soap:body use-"literal"/» 
«/wsdl:input» 
«wsdl:output» 
«soap:body use-"literal"/» 
«/wsdl:output» 
«/wsdl:operation» 
«wsdl:operation name="submitRejectRqst'» 
«soap:operation soapAction-"submitRejectRqst" style-"document"/» 
«wsdl:input» 
«soap:body use-"literal"/» 
«/wsdl:input» 
«wsdl:output» 
«soap:body use-"literal"/» 
«/wsdl:output» 
«/wsdl:operation» 
«wsdl:operation name-"submitBatchRqst"» 
«soap:operation soapAction-"submitBatchRqst" style-"document"/» 
«wsdl:input» 
«soap:body use-"literal"/» 
«/wsdl:input» 
«wsdl:output» 
«soap:body use-"literal"/» 
«/wsdl:output» 
«/wsdl:operation» 
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«wsdl:operation name="submitGetRgst"> 
«soap:operation soapAction="submitGetRqst" style-"document"/» 
«wsdl:input» 

«soap:body use-"literal"/» 
«/wsdl:input» 

«wsdl:output» 

«soap:body use-"literal"/» 
«/wsdl:output» 

«/wsdl:operation» 

«wsdl:operation name-"submitGetSedGrpOffersRqst"» 
«soap:operation soapAction="submitGetSedGrpOffersRqst" 
style="document "/» 
<wsdl:input> 

«soap:body use-"literal"/» 
«/wsdl:input» 
«wsdl:output» 
«soap:body use-"literal"/» 
«/wsdl:output» 

«/wsdl:operation» 

«wsdl:operation name="submitServerStatusRqst"» 
«soap:operation soapAction="submitServerStatusRqst" 
style="document "/» 

«wsdl:input» 
«soap:body use-"literal"/» 
«/wsdl:input» 
«wsdl:output» 
«soap:body use-"literal"/» 
«/wsdl:output» 
«/wsdl:operation» 
«/wsdl:binding» 
«wsdl: service name="spppService"> 

«wsdl:port name="spppPort" binding=" sppfs: sppp$oapBinding"> 
<soap:address location-"REPLACE WITH ACTUAL URL"/» 

«/wsdl:port» 

«/wsdl:service» 
«/wsdl:definitions» 


Figure 2: WSDL 
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10. SPPP over SOAP Examples 


This section shows an XML message exchange between two SIP Service 
Providers (SSPs) and a Registry. The messages in this section are 
valid XML instances that conform to the SPPP over SOAP schema version 
within this document. This section also relies on the XML data 
structures defined in the SPPF specification [RFC7877], which should 
also be referenced to understand XML object types embedded in these 
example messages. 


In this sample use-case scenario, SSP1 and SSP2 provision resource 
data in the Registry and use SPPF constructs to selectively share the 
SED Groups. In the figure below, SSP2 has two ingress Signaling Path 
Border Element (SBE) instances that are associated with the Public 
Identities with which SSP2 has the retail relationship. Also, the 
two SBE instances for SSPI are used to show how to use SPPF to 
associate route preferences for the destination Ingress Routes and 
exercise greater control on outbound traffic to the peer’s ingress 


SBEs. 
=-= + qp—————————————————— 
| | 
+----—-- + +----—-- + 
| sbei | | sbe2 | 
+----—-- + +----—-- + 
SSP1 | | SSP2 
+----—-- + +----—-- + 
| sbe3 | | sbe4 | 
+---—-—-- + +----—-- + 
iana-en:111 | | iana-en:222 
—————————————— + +—————————————————— 
| | 
| | 
| SPPF = +------------------ +  SPPF | 
Ho -- > | Registry «-------- + 
R-—---------------- * 


Example Use-Case Infrastructure 
10.1. Add Destination Group 
SSP2 adds a Destination Group to the Registry for later use. The 
SSP2 SPPF client sets a unique transaction identifier "txn 1479" for 


tracking purposes. The name of the Destination Group is set to 
DEST GRP SSP2 1. 
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«?xml version-"1.0" encoding-"UTF-8"?» 
«soapenv:Envelope 
xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:urnl="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 
<urn: spppAddRequest> 
<!--Optional:--> 
<clientTransId>txn_1479</clientTransId> 
<!--1 or more repetitions:--> 
<obj xsi:type="urnl:DestGrpType"> 
<urnl:rant>iana-en:222</urnl:rant> 
<urnl:rar>iana-en:223</urnl:rar> 
<urn1:dgName>DEST_GRP_SSP2_1</urnl:dgName> 
</obj> 
</urn:spppAddReguest> 
</soapenv:Body> 
</soapenv:Envelope> 


The Registry processes the reguest and returns a favorable response 
confirming successful creation of the named Destination Group. In 
addition to returning a unigue server transaction identifier, the 
Registry returns the matching client transaction identifier from the 
reguest message back to the SPPF client. 


<?xml version="1.0" encoding-"UTF-8"?» 

«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/"» 
«S:Body» 

«ns3: spppAddResponse 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
<clientTransId>txn_1479</clientTransId> 
«serverTransId»tx 12345«/serverTransId» 
<overallResult> 

<code>1000</code> 
<msg>Request Succeeded.</msg> 
</overallResult> 
</ns3:spppAddResponse> 
</S:Body> 
</S:Envelope> 
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10.2. Add SED Records 
SSP2 adds SED Records in the form of Ingress Routes to the Registry. 


«?xml version="1.0" encoding-"UTF-8"?» 
«soapenv:Envelope 
xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:urnl="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 
<urn: spppAddRequest> 
<!--Optional:--> 
<clientTransId>txn_1479</clientTransId> 
<!--1 or more repetitions:--> 
<obj xsi:type="urnl:NAPTRType"> 
<urnl:rant>iana-en:222</urnl:rant> 
<urnl:rar>iana-en:223</urnl:rar> 
«urnl:sedName»SED SSP2 SBE2«/urnl:sedName» 
<urnl:isInSvc>true</urnl:isInSvc> 
<urnl:order>10</urnl:order> 
<urnl:flags>u</urnl:flags> 
<urnl:svcs>E2U+sip</urnl:svcs> 
<urnl:regx> 
<urnl:ere>” (.*) $</urnl:ere> 
<urnl:repl>sip:\1@sbe2.ssp2.example.com</urnl:repl> 
«/urnl:regx» 
«/obj» 
</urn:spppAddReguest> 
</soapenv:Body> 
</soapenv:Envelope> 
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The Registry returns a success response. 


«?xml version="1.0" encoding-"UTF-8"?» 

«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/"» 
«S:Body» 

«ns3: spppAddResponse 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
<clientTransId>txn_1479</clientTransId> 
<serverTransId>tx_12345</serverTransId> 
<overallResult> 

<code>1000</code> 
<msg>Request Succeeded.</msg> 
</overallResult> 
</ns3:spppAddResponse> 
</S:Body> 
</S:Envelope> 


10.3. Add SED Records -- URIType 


SSP2 adds another SED Record to the Registry and makes use of 
URIType. 


<?xml version="1.0" encoding-"UTF-8"?» 
<soapenv: Envelope 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:urnl="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 
<urn: spppAddRequest> 
<clientTransId>txn_1479</clientTransId> 
<!--1 or more repetitions:--> 
«obj xsi:type="urnl:URIType"> 
<urnl:rant>iana-en:222</urnl:rant> 
<urnl:rar>iana-en:223</urnl:rar> 
«urnl:sedName»SED SSP2 SBE4«/urnl:sedName» 
<urnl:isInSvc>true</urnl:isInSvc> 
«urnl:ere»^(.*)$«/urnl:ere» 
<urnl:uri>sip:11;npditsbe4.ssp2.example.com</urnl:uri> 
«/obj» 
</urn: spppAddRequest> 
</soapenv: Body» 
</soapenv:Envelope> 
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The Registry returns a success response. 


«?xml version="1.0" encoding-"UTF-8"?» 
«S:Envelope xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/"» 
«S:Body» 

«ns3: spppAddResponse 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
<clientTransId>txn_1479</clientTransId> 
«serverTransId»tx 12345«/serverTransId» 
<overallResult> 

<code>1000</code> 
<msg>Request Succeeded.</msg> 
</overallResult> 
</ns3:spppAddResponse> 
</S:Body> 
</S:Envelope> 
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10. 


Add SED Group 


SSP2 creates the grouping of SED Records (e.g., Ingress Routes) and 
chooses a higher precedence for SED SSP2 SBE2 by setting a lower 
number for the "priority" attribute, a protocol agnostic precedence 
indicator. 


«?xml version="1.0" encoding-"UTF-8"?» 

«soapenv:Envelope 
xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:urnl="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 

«urn:spppAddRequest» 
«clientTransId»txn 1479«/clientTransId» 


<!--1 or more repetitions:--> 


«obj xsi:type="urnl:SedGrpType"> 


<urnl:rant>iana-en:222</urnl:rant> 

<urnl:rar>iana-en:223</urnl:rar> 

<urnl: sedGrpName>SED_GRP_SSP2_1</urnl:sedGrpName> 

<urnl:sedRecRef> 

<urnl:sedKey xsi:type="urn:ObjKeyType"> 
<rant>iana-en:222</rant> 
<name>SED_SSP2_SBE2</name> 
<type>SedRec</type> 

</urnl:sedKey> 
<urnl:priority>100</urnl:priority> 

</urnl:sedRecRef> 

<urn1l:dgName>DEST_GRP_SSP2_1</urnl:dgName> 

<urnl:isInSvc>true</urnl:isInSvc> 

<urnl:priority>10</urnl:priority> 


</obj> 
</urn:spppAddReguest> 
</soapenv:Body> 
</soapenv:Envelope> 
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To confirm successful processing of this request, the Registry 
returns a well-known result code "1000" to the SSP2 client. 


<?xml version="1.0" encoding-"UTF-8"?» 
«S:Envelope xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/"» 
«S:Body» 

«ns3: spppAddResponse 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
<clientTransId>txn_1479</clientTransId> 
<serverTransId>tx_12345</serverTransId> 
<overallResult> 

<code>1000</code> 
<msg>Request Succeeded.</msg> 
</overallResult> 
</ns3:spppAddResponse> 
</S:Body> 
</S:Envelope> 


10.5. Add Public Identifier -- Successful COR Claim 


SSP2 activates a TN Public Identifier by associating it with a valid 
Destination Group. Further, SSP2 puts forth a claim that it is the 
carrier-of-record (COR) for the TN. 


«soapenv:Envelope 
xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:urnl="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 
«urn:spppAddRequest» 
«clientTransId»txn 1479«/clientTransId» 
<!--1 or more repetitions:--> 
«obj xsi:type="urnl:TNType"> 
<urnl:rant>iana-en:222</urnl:rant> 
<urnl:rar>iana-en:223</urnl:rar> 
<urn1l:dgName>DEST_GRP_SSP2_1</urnl:dgName> 
<urnl:tn>+12025556666</urnl:tn> 
<urnl:corInfo> 
<urnl:corClaim>true</urnl:corClaim> 
</urnl:corInfo> 
</obj> 
</urn:spppAddReguest> 
</soapenv:Body> 
</soapenv:Envelope> 
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Assuming that the Registry has access to TN authority data and it 
performs the required checks to verify that SSP2 is in fact the SP of 
record for the given TN, the request is processed successfully. In 
the response message, the Registry sets the value of «cor» to "true" 
in order to confirm the SSP2 claim as the carrier-of-record, and the 
«corDate» reflects the time when the carrier-of-record claim is 
processed. 


«?xml version="1.0" encoding-"UTF-8"?» 

«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<S:Body> 

«ns3:spppAddResponse 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
«clientTransId»txn 1479«/clientTransId» 
«serverTransId»tx 12345«/serverTransId» 
<overallResult> 

<code>1000</code> 

<msg>Request Succeeded.</msg> 

</overallResult> 

<detailResult> 

<code>1000</code> 

<msg>Request Succeeded.</msg> 

«obj xsi:type="ns2:TNType"> 
<ns2:rant>iana-en:222</ns2:rant> 
<ns2:rar>iana-en:223</ns2:rar> 
<ns2:cDate>2010-05-30T09:30:10Z</ns2:cDate> 

«ns2:dgName»DEST GRP SSP2 1«/ns2:dgName» 

«ns2:tn»+12025556666«/ns2:tn» 

«ns2:corInfo» 
<ns2:corClaim>true</ns2:corClaim> 
<ns2:cor>true</ns2:cor> 
<ns2:corDate>2010-05-30T09:30:11Z</ns2:corDate> 

</ns2:corInfo> 

</obj> 
</detailResult> 
</ns3:spppAddResponse> 
</S:Body> 
</S:Envelope> 
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10. 


6. Add LRN 


If another entity that SSP2 shares SED (e.g., routes) 


August 2016 


with has access 


to Number Portability data, it may choose to perform route lookups by 
RN. Therefore, SSP2 associates an RN to a Destination Group in order 


to facilitate Ingress Route discovery. 


«?xml version="1.0" encoding-"UTF-8"?» 
«soapenv:Envelope 


xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 


xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:urnl="urn:ietf:params:xml:ns:sppf:base:1" 


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 


<soapenv:Header/> 
<soapenv:Body> 
<urn: spppAddRequest> 
<clientTransId>txn_1479</clientTransId> 
<!--1 or more repetitions:--> 
«obj xsi:type="urnl:RNType"> 
<urnl:rant>iana-en:222</urnl:rant> 
<urnl:rar>iana-en:223</urnl:rar> 
<urn1:dgName>DEST_GRP_SSP2_1</urnl:dgName> 
<urnl:rn>2025550000</urnl:rn> 
</obj> 
</urn:spppAddReguest> 
</soapenv:Body> 
</soapenv:Envelope> 
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The Registry completes the request successfully and returns a 
favorable response to the SPPF client. 


«?xml version="1.0" encoding-"UTF-8"?» 

«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/"» 
«S:Body» 

«ns3: spppAddResponse 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
«clientTransId»txn 1479«/clientTransId» 
«serverTransId»tx 12345«/serverTransId» 
<overallResult> 

<code>1000</code> 

<msg>Request Succeeded.</msg> 

</overallResult> 
</ns3:spppAddResponse> 
</S:Body> 

</S:Envelope> 


10.7. Add TN Range 


Next, SSP2 activates a block of ten thousand TNs and associates it to 
a Destination Group. 


<?xml version="1.0" encoding-"UTF-8"?» 
<soapenv: Envelope 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:urnl="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 
«urn:spppAddRequest» 
«clientTransId»txn 1479«/clientTransId» 
<!--1 or more repetitions:--> 
«obj xsi:type="urnl:TNRType"> 
<urnl:rant>iana-en:222</urnl:rant> 
<urnl:rar>iana-en:223</urnl:rar> 
<urn1l:dgName>DEST_GRP_SSP2_1</urnl:dgName> 
<urnl:range> 
<urnl:startTn>+12026660000</urnl:startTn> 
<urnl:endTn>+12026669999</urnl:endTn> 
</urnl:range> 
</obj> 
</urn:spppAddReguest> 
</soapenv:Body> 
</soapenv:Envelope> 
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The Registry completes the request successfully and returns a 
favorable response. 


«?xml version="1.0" encoding-"UTF-8"?» 

«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/"» 
«S:Body» 

«ns3: spppAddResponse 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
«clientTransId»txn 1479«/clientTransId» 
«serverTransId»tx 12345«/serverTransId» 
<overallResult> 

<code>1000</code> 

<msg>Request Succeeded.</msg> 

</overallResult> 
</ns3:spppAddResponse> 
</S:Body> 

</S:Envelope> 


10.8. Add TN Prefix 


2016 


Next, SSP2 activates a block of ten thousand TNs by using the TNPType 


structure and identifying a TN prefix. 


«?xml version="1.0" encoding-"UTF-8"?» 
«soapenv:Envelope 
xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:urnl="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 
«urn:spppAddRequest» 
«clientTransId»txn 1479«/clientTransId» 
<!--1 or more repetitions:--> 
«obj xsi:type="urnl:TNPType"> 
<urnl:rant>iana-en:222</urnl:rant> 
<urnl:rar>iana-en:223</urnl:rar> 
<urn1l:dgName>DEST_GRP_SSP2_1</urnl:dgName> 
<urnl:tnPrefix>+1202777</urnl:tnPrefix> 
</obj> 
</urn:spppAddReguest> 
</soapenv:Body> 
</soapenv:Envelope> 
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The Registry completes the request successfully and returns a 
favorable response. 


«?xml version="1.0" encoding-"UTF-8"?» 

«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/"» 
«S:Body» 

«ns3: spppAddResponse 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
«clientTransId»txn 1479«/clientTransId» 
«serverTransId»tx 12345«/serverTransId» 
<overallResult> 

<code>1000</code> 

<msg>Request Succeeded.</msg> 

</overallResult> 
</ns3:spppAddResponse> 
</S:Body> 

</S:Envelope> 


2016 
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10.9. Enable Peering -- SED Group Offer 


In order for SSP1 to complete session establishment for a destination 
TN where the target subscriber has a retail relationship with SSP2, 
it first requires an asynchronous bidirectional handshake to show 
mutual consent. To start the process, SSP2 initiates the peering 
handshake by offering SSP1 access to its SED Group. 


«?xml version="1.0" encoding-"UTF-8"?» 
«soapenv:Envelope 
xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:urnl="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 
<urn: spppAddRequest> 
<clientTransId>txn_1479</clientTransId> 
<!--1 or more repetitions:--> 
«obj xsi:type="urnl:SedGrpOfferType"> 
<urnl:rant>iana-en:222</urnl:rant> 
<urnl:rar>iana-en:223</urnl:rar> 
<urnl:sedGrpOfferKey xsi:type="urn:SedGrpOfferKeyType"> 
<sedGrpKey xsi:type="urn:ObjKeyType"> 
<rant>iana-en:222</rant> 
<name>SED_GRP_SSP2_1</name> 
<type>SedGrp</type> 
</sedGrpKey> 
<offeredTo>iana-en:111</offeredTo> 
«/urnl:sedGrpOfferKey» 
<urnl:status>offered</urnl:status> 
<urnl:offerDateTime> 
2006-05-04T18:13:51.02 
</urnl:offerDateTime> 
«/obj» 
</urn:spppAddReguest> 
</soapenv:Body> 
</soapenv:Envelope> 
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The Registry completes the request successfully and confirms that the 
SSPI will now have the opportunity to weigh in on the offer and 
either accept or reject it. The Registry may employ out-of-band 
notification mechanisms for quicker updates to SSP1 so they can act 
faster, though this topic is beyond the scope of this document. 


«?xml version="1.0" encoding-"UTF-8"?» 

«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/"» 
«S:Body» 

«ns3: spppAddResponse 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
<clientTransId>txn_1479</clientTransId> 
<serverTransId>tx_12345</serverTransId> 
<overallResult> 

<code>1000</code> 

<msg>Reguest Succeeded.</msg> 

</overallResult> 
</ns3:spppAddResponse> 
</S:Body> 

</S:Envelope> 


Cartwright, et al. Standards Track [Page 57] 


RFC 7878 SPP Protocol over SOAP August 2016 


10.10. Enable Peering -- SED Group Offer Accept 


SSP1 responds to the offer from SSP2 and agrees to have visibility to 
SSP2 SED (e.g., Ingress Routes). 


<?xml version="1.0" encoding-"UTF-8"?» 
«soapenv:Envelope 
xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn-"urn:ietf:params:xml:ns:sppf:soap:l1"» 
«soapenv:Header/» 
«soapenv:Body» 
«urn:spppAcceptRequest» 
<!--Optional:--> 
<clientTransId>txn_1479</clientTransId> 
<!--1 or more repetitions:--> 
«sedGrpOfferKey» 
«sedGrpKey» 
<rant>iana-en:222</rant> 
<name>SED_GRP_SSP2_1</name> 
<type>SedGrp</type> 
</sedGrpKey> 
<offeredTo>iana-en:111</offeredTo> 
«/sedGrpOfferKey» 
</urn: spppAcceptRequest> 
</soapenv:Body> 
</soapenv:Envelope> 


Cartwright, et al. Standards Track [Page 58] 


RFC 7878 SPP Protocol over SOAP August 2016 


The Registry confirms that the request has been processed 
successfully. From this point forward, if SSP1 looks up a Public 
Identifier through the query resolution server, where the Public 
Identifier is part of the Destination Group by way of 
"SED GRP SSP2 1" SED association, SSP2 ingress SBE information will 
be shared with SSP1. 


«?xml version="1.0" encoding-"UTF-8"?» 

«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/"» 
«S:Body» 

<ns3: spppAccept Response 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
<clientTransId>txn_1479</clientTransId> 
<serverTransId>tx_12350</serverTransId> 
<overallResult> 
<code>1000</code> 
<msg>Reguest Succeeded.</msg> 
</overallResult> 
«/ns3:spppAcceptResponse» 
«/S:Body» 
«/S:Envelope» 
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10.11. Add Egress Route 


SSPI wants to prioritize all outbound traffic to the Ingress Route 
associated with the "SED GRP SSP2 1" SED Group record, through 
"sbel.sspl.example.com". 


«?xml version="1.0" encoding-"UTF-8"?» 
«soapenv:Envelope 
xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:urnl="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 
<urn: spppAddRequest> 
<clientTransId>txn_1479</clientTransId> 
<!--1 or more repetitions:--> 
<obj xsi:type="urnl:EgrRteType"> 
<urnl:rant>iana-en:222</urnl:rant> 
<urnl:rar>iana-en:223</urnl:rar> 
«urnl:egrRteName»EGR RTE 01«/urnl:egrRteName» 
<urnl:pref>50</urnl:pref> 
<urnl:regxRewriteRule> 
<urnl:ere>” (.*Q) (.*) $</urnl:ere> 
<urnl:rep1>1112?route=sbel.sspl.example.com</urnl:repl> 
</urnl:regxRewriteRule> 
«urnl:ingrSedGrp xsi:type-"urn:ObjKeyType"» 
<rant>iana-en:222</rant> 
<name>SED_GRP_SSP2_1</name> 
<type>SedGrp</type> 
</urnl:ingrSedGrp> 
</obj> 
</urn:spppAddReguest> 
</soapenv:Body> 
</soapenv:Envelope> 
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Since peering has already been established, the request to add the 
Egress Route has been successfully completed. 


«?xml version="1.0" encoding-"UTF-8"?» 

«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/"» 
«S:Body» 

«ns3: spppAddResponse 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
«clientTransId»txn 1479«/clientTransId» 
«serverTransId»tx 12345«/serverTransId» 
<overallResult> 

<code>1000</code> 

<msg>Request Succeeded.</msg> 

</overallResult> 
</ns3:spppAddResponse> 
</S:Body> 

</S:Envelope> 


10.12. Remove Peering -- SED Group Offer Reject 


Earlier, SSP1 had accepted having visibility to SSP2 SED. SSP1 now 
decides to no longer maintain this visibility; hence, it rejects the 
SED Group Offer. 


<?xml version="1.0" encoding-"UTF-8"?» 
<soapenv: Envelope 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn-"urn:ietf:params:xml:ns:sppf:soap:l1"» 
«soapenv:Header/» 
«soapenv:Body» 
<urn: spppRejectRequest> 
<!--Optional:--> 
<clientTransId>txn_1479</clientTransId> 
<!--1 or more repetitions:--> 
«sedGrpOfferKey» 
«sedGrpKey» 
<rant>iana-en:222</rant> 
<name>SED_GRP_SSP2_1</name> 
<type>SedGrp</type> 
</sedGrpKey> 
<offeredTo>iana-en:111</offeredTo> 
«/sedGrpOfferKey» 
«/urn:spppRejectRequest» 
«/soapenv: Body» 
«/soapenv:Envelope» 
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10. 


The Registry confirms that the request has been processed 
successfully. From this point forward, if SSP1 looks up a Public 
Identifier through the query resolution server, where the Public 
Identifier is part of the Destination Group by way of 
"SED GRP SSP2 1" SED association, SSP2 ingress SBE information will 
not be shared with SSP1; hence, an SSP2 ingress SBE will not be 
returned in the query response. 


<?xml version="1.0" encoding-"UTF-8"?» 

«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/"» 
«S:Body» 

«ns3: spppRejectResponse 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
«clientTransId»txn 1479«/clientTransId» 
«serverTransId»tx 12350«/serverTransId» 
<overallResult> 

<code>1000</code> 
<msg>Request Succeeded.</msg> 
</overallResult> 

«/ns3:spppRejectResponse» 

«/S:Body» 
«/S:Envelope» 


13. Get Destination Group 


SSP2 uses the spppGetRequest operation to tally the last provisioned 
record for Destination Group DEST GRP SSP2 1. 


<?xml version="1.0" encoding-"UTF-8"?» 
«soapenv:Envelope 
xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 
<urn: spppGetRequest> 
<!--1 or more repetitions:--> 
<objKey xsi:type="urn:ObjKeyType"> 
<rant>iana-en:222</rant> 
<name>DEST_GRP_SSP2_1</name> 
<type>DestGrp</type> 
</objKey> 
</urn: spppGetRequest> 
</soapenv: Body» 
</soapenv:Envelope> 
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The Registry completes the request successfully and returns a 
favorable response. 


«?xml version="1.0" encoding-"UTF-8"?» 

«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<S:Body> 

<ns3: spppGet Response 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
<overallResult> 
<code>1000</code> 
<msg>success</msg> 
</overallResult> 
«resultObj xsi:type="ns2:DestGrpType"> 
<ns2:rant>iana-en:222</ns2:rant> 
<ns2:rar>iana-en:223</ns2:rar> 
<ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate> 
<ns2:dgName>DEST_GRP_SSP2_1</ns2:dgName> 
</resultObj> 
</ns3:spppGet Response> 
</S:Body> 
</S:Envelope> 


2016 


Cartwright, et al. Standards Track [Page 63] 


RFC 7878 SPP Protocol over SOAP August 2016 


10.14. Get Public Identifier 


SSP2 obtains the last provisioned record associated with a given TN. 


«?xml version="1.0" encoding-"UTF-8"?» 
«soapenv:Envelope 
xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:urnl="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 
<urn: spppGetRequest> 
<!--1 or more repetitions:--> 
<objKey xsi:type="urn:PubldKeyType"> 
<rant>iana-en:222</rant> 
<number> 
<urnl:value>+12025556666</urnl:value> 
<urnl:type>TN</urnl:type> 
</number> 
</objKey> 
</urn:spppGetReguest> 
</soapenv:Body> 
</soapenv:Envelope> 
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The Registry completes the request successfully and returns a 
favorable response. 


«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<S:Body> 

<ns3: spppGet Response 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
<overallResult> 

<code>1000</code> 

<msg>success</msg> 

</overallResult> 

<resultObj xsi:type="ns2:TNType"> 
<ns2:rant>iana-en:222</ns2:rant> 
<ns2:rar>iana-en:223</ns2:rar> 
<ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate> 

«ns2:dgName»DEST GRP SSP2 1«/ns2:dgName» 

«ns2:tn»+12025556666«/ns2:tn» 

«ns2:corInfo» 
<ns2:corClaim>true</ns2:corClaim> 
<ns2:cor>true</ns2:cor> 
<ns2:corDate>2010-05-30T09:30:10Z</ns2:corDate> 

«/ns2:corInfo» 

</resultObj> 
</ns3:spppGetResponse> 
</S:Body> 
</S:Envelope> 
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10.15. Get SED Group Request 


SSP2 obtains the last provisioned record for the SED Group 
SED GRP SSP2 1. 


«?xml version="1.0" encoding-"UTF-8"?» 
«soapenv:Envelope 
xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 
<urn: spppGetRequest> 
<!--1 or more repetitions:--> 
<objKey xsi:type="urn:ObjKeyType"> 
<rant>iana-en:222</rant> 
<name>SED_GRP_SSP2_1</name> 
<type>SedGrp</type> 
</objKey> 
</urn: spppGetRequest> 
</soapenv:Body> 
</soapenv:Envelope> 
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The Registry completes the request successfully and returns a 
favorable response. 


«?xml version="1.0" encoding-"UTF-8"?» 

«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<S:Body> 

<ns3: spppGet Response 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
<overallResult> 
<code>1000</code> 
<msg>success</msg> 
</overallResult> 
«resultObj xsi:type="ns2:SedGrpType"> 
<ns2:rant>iana-en:222</ns2:rant> 
<ns2:rar>iana-en:223</ns2:rar> 
<ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate> 
<ns2: sedGrpName>SED_GRP_SSP2_1</ns2:sedGrpName> 
<ns2:sedRecRef> 
<ns2:sedKey xsi:type="ns3:ObjKeyType"> 
<rant>iana-en:222</rant> 
<name>SED_SSP2_SBE2</name> 
<type>SedRec</type> 
</ns2:sedKey> 
<ns2:priority>100</ns2:priority> 
</ns2:sedRecRef> 
<ns2:sedRecRef> 
<ns2:sedKey xsi:type="ns3:ObjKeyType"> 
<rant>iana-en:222</rant> 
<name>SED_SSP2_SBE4</name> 
<type>SedRec</type> 
</ns2:sedKey> 
<ns2:priority>101</ns2:priority> 
</ns2:sedRecRef> 
«ns2:dgName»DEST GRP SSP2 1«/ns2:dgName» 
<ns2:isInSvc>true</ns2:isInSvc> 
<ns2:priority>10</ns2:priority> 
</resultObj> 
«/ns3:spppGetResponse» 
«/S:Body» 
«/S:Envelope» 
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10.16. Get SED Group Offers Request 


SSP2 fetches the last provisioned SED Group Offer to the «peeringOrg» 
SSP1. 


<?xml version="1.0" encoding-"UTF-8"?» 
<soapenv: Envelope 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1"> 
<soapenv:Header/> 
<soapenv:Body> 
«urn:getSedGrpOffersRequest» 
<offeredTo>iana-en:111</offeredTo> 
«/urn:getSedGrpOffersRequest» 
</soapenv:Body> 
</soapenv:Envelope> 
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The Registry processes the request successfully and returns a 
favorable response. 


«?xml version="1.0" encoding-"UTF-8"?» 
«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<S:Body> 
<ns3: spppGet Response 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
<overallResult> 
<code>1000</code> 
<msg>success</msg> 
</overallResult> 
<resultObj xsi:type="ns2:SedGrpOfferType"> 
<ns2:rant>iana-en:222</ns2:rant> 
<ns2:rar>iana-en:223</ns2:rar> 
<ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate> 
<ns2:sedGrpOfferKey 
xsi:type="ns3:SedGrpOfferKeyType"> 
<sedGrpKey> 
<rant>iana-en:222</rant> 
<name>SED_GRP_SSP2_1</name> 
<type>SedGrp</type> 
</sedGrpKey> 
<offeredTo>iana-en:111</offeredTo> 
</ns2:sedGrpOfferKey> 
<ns2:status>offered</ns2:status> 
<ns2:offerDateTime> 
2006-05-04T18:13:51.02 
«/ns2:offerDateTime» 
</resultObj> 
</ns3:spppGetResponse> 
</S:Body> 
</S:Envelope> 
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10.17. Get Egress Route 


SSP1 wants to verify the last provisioned record for the Egress Route 
called EGR RTE 01. 


«?xml version="1.0" encoding-"UTF-8"?» 
«soapenv:Envelope 
xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 
<urn: spppGetRequest> 
<!--1 or more repetitions:--> 
<objKey xsi:type="urn:ObjKeyType"> 
<rant>iana-en:111</rant> 
<name>EGR_RTE_01</name> 
<type>EgrRte</type> 
</objKey> 
</urn: spppGetRequest> 
</soapenv:Body> 
</soapenv:Envelope> 
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The Registry completes the request successfully and returns a 
favorable response. 


«?xml version="1.0" encoding-"UTF-8"?» 

«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<S:Body> 

<ns3: spppGet Response 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
<overallResult> 

<code>1000</code> 

<msg>success</msg> 

</overallResult> 

<resultObj xsi:type="ns2:EgrRteType"> 
<ns2:rant>iana-en:222</ns2:rant> 
<ns2:rar>iana-en:223</ns2:rar> 
<ns2:cDate>2012-10-22T09:30:10Z</ns2:cDate> 
<ns2:egrRteName>EGR_RTE_01</ns2:egrRteName> 
<ns2:pref>50</ns2:pref> 

<ns2:regxRewriteRule> 
<ns2:ere>” (.*)$</ns2:ere> 
«ns2:replXsip:`1Gsbel.sspl.example.com«/ns2:repl» 

«/ns2:regxRewriteRule» 

«ns2:ingrSedGrp xsi:type="ns3:ObjKeyType"> 
<rant>iana-en:222</rant> 
<name>SED_GRP_SSP2_1</name> 
<type>SedRec</type> 

</ns2:ingrSedGrp> 

</resultObj> 
</ns3:spppGetResponse> 
</S:Body> 

</S:Envelope> 
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10.18. Delete Destination Group 


SSP2 initiates a request to delete the Destination Group 
DEST GRP SSP2 1. 


«?xml version="1.0" encoding-"UTF-8"?» 
«soapenv:Envelope 
xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 
<urn:spppDelReguest> 
<!--1 or more repetitions:--> 
<objKey xsi:type="urn:ObjKeyType"> 
<rant>iana-en:222</rant> 
<name>DEST_GRP_SSP2_1</name> 
<type>DestGrp</type> 
</objKey> 
</urn:spppDelReguest> 
</soapenv:Body> 
</soapenv:Envelope> 


The Registry completes the reguest successfully and returns a 
favorable response. 


<?xml version="1.0" encoding-"UTF-8"?» 

«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/"» 
«S:Body» 

«ns3: spppDelResponse 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
<serverTransId>tx_12354</serverTransId> 
<overallResult> 

<code>1000</code> 

<msg>Request Succeeded.</msg> 

</overallResult> 
</ns3:spppDelResponse> 
</S:Body> 

</S:Envelope> 
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10.19. Delete Public Identifier 
SSP2 chooses to deactivate the TN and remove it from the Registry. 


«?xml version="1.0" encoding-"UTF-8"?» 
«soapenv:Envelope 
xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:urnl="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 
<urn: spppDelRequest> 
<!--1 or more repetitions:--> 
<objKey xsi:type="urn:PubldKeyType"> 
<rant>iana-en:222</rant> 
<number> 
<urnl:value>+12025556666</urnl:value> 
<urnl:type>TN</urnl:type> 
</number> 
</objKey> 
</urn:spppDelReguest> 
</soapenv:Body> 
</soapenv:Envelope> 


The Registry completes the reguest successfully and returns a 
favorable response. 


<?xml version="1.0" encoding-"UTF-8"?» 

«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/"» 
«S:Body» 

«ns3: spppDelResponse 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
«serverTransId»tx 12354«/serverTransId» 
<overallResult> 

<code>1000</code> 

<msg>Request Succeeded.</msg> 

</overallResult> 
</ns3:spppDelResponse> 
</S:Body> 

</S:Envelope> 
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10.20. Delete SED Group Request 
SSP2 removes the SED Group called SED GRP SSP2 1. 


«?xml version="1.0" encoding-"UTF-8"?» 
«soapenv:Envelope 
xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 
<urn:spppDelReguest> 
<!--1 or more repetitions:--> 
<objKey xsi:type="urn:ObjKeyType"> 
<rant>iana-en:222</rant> 
<name>SED_GRP_SSP2_1</name> 
<type>SedGrp</type> 
</objKey> 
</urn:spppDelReguest> 
</soapenv:Body> 
</soapenv:Envelope> 


The Registry completes the reguest successfully and returns a 
favorable response. 


<?xml version="1.0" encoding-"UTF-8"?» 

«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/"» 
«S:Body» 

«ns3: spppDelResponse 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
«serverTransId»tx 12354«/serverTransId» 
<overallResult> 

<code>1000</code> 

<msg>Request Succeeded.</msg> 

</overallResult> 
</ns3:spppDelResponse> 
</S:Body> 

</S:Envelope> 
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10.21. Delete SED Group Offers Request 


SSP2 no longer wants to share SED Group SED GRP SSP2 1 with SSP1. 


<?xml version="1.0" encoding-"UTF-8"?» 

«soapenv:Envelope 
xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 

<urn:spppDelReguest> 


<!--1 or more repetitions:--> 
<objKey xsi:type="urn:SedGrpOfferKeyType"> 
<sedGrpKey> 


<rant>iana-en:222</rant> 
<name>SED_GRP_SSP2_1</name> 
<type>SedGrp</type> 

</sedGrpKey> 

<offeredTo>iana-en:111</offeredTo> 

</objKey> 
«/urn:spppDelRequest» 
</soapenv:Body> 
</soapenv:Envelope> 


The Registry completes the reguest successfully and returns a 
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favorable response. Restoring this resource sharing will reguire a 
new SED Group Offer from SSP2 to SSP1 followed by a successful SED 


Group Accept reguest from SSP1. 


<?xml version="1.0" encoding-"UTF-8"?» 

«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/"» 
«S:Body» 

«ns3: spppDelResponse 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
«serverTransId»tx 12354«/serverTransId» 
<overallResult> 

<code>1000</code> 

<msg>Request Succeeded.</msg> 

</overallResult> 
</ns3:spppDelResponse> 
</S:Body> 

</S:Envelope> 


Cartwright, et al. Standards Track [Page 75] 


RFC 7878 SPP Protocol over SOAP August 2016 


10.22. Delete Egress Route 
SSP1 decides to remove the Egress Route with the label EGR RTE 01. 


«?xml version="1.0" encoding-"UTF-8"?» 
«soapenv:Envelope 
xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 
<urn:spppDelReguest> 
<!--1 or more repetitions:--> 
<objKey xsi:type="urn:ObjKeyType"> 
<rant>iana-en:111</rant> 
<name>EGR_RTE_01</name> 
<type>EgrRte</type> 
</objKey> 
«/urn:spppDelRequest» 
</soapenv:Body> 
</soapenv:Envelope> 


The Registry completes the reguest successfully and returns a 
favorable response. 


<?xml version="1.0" encoding-"UTF-8"?» 

«S:Envelope 
xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/"» 
«S:Body» 

«ns3: spppDelResponse 
xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 
«serverTransId»tx 12354«/serverTransId» 
<overallResult> 

<code>1000</code> 

<msg>Request Succeeded.</msg> 

</overallResult> 
</ns3:spppDelResponse> 
</S:Body> 

</S:Envelope> 
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10.23. Batch Request 


Following is an example of how some of the operations mentioned in 
previous sections MAY be performed by an SPPF client as a batch in 
one single SPPP over SOAP request. 


In the sample request below, SSP1 wants to accept a SED Group Offer 
from SSP3, add a Destination Group, add a Naming Authority Pointer 
(NAPTR) SED Record, add a SED Group, add a SED Group Offer, delete a 
previously provisioned TN type Public Identifier, delete a previously 
provisioned SED Group, and reject a SED Group Offer from SSP4. 


<?xml version="1.0" encoding-"UTF-8"?» 
«soapenv:Envelope 
xmlns:soapenv-"http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppf:soap:1" 
xmlns:urnl="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
<soapenv:Header/> 
<soapenv:Body> 
<urn:spppBat chReguest> 
<clientTransId>txn_1467</clientTransId> 
<minorVer>1</minorVer> 


«acceptSedGrpOffer» 

«sedGrpKey» 
<rant>iana-en:225</rant> 
<name>SED_SSP3_SBE1_Offered</name> 
<type>SedGrp</type> 

</sedGrpKey> 

<offeredTo>iana-en:222</offeredTo> 

«/acceptSedGrpOffer» 


«addObj xsi:type-"urnl:DestGrpType"» 
<urnl:rant>iana-en:222</urnl:rant> 
<urnl:rar>iana-en:223</urnl:rar> 
<urn1l:dgName>DEST_GRP_SSP2_1</urnl:dgName> 

</addObj> 


<addObj xsi:type="urnl:NAPTRType"> 
<urnl:rant>iana-en:222</urnl:rant> 
<urnl:rar>iana-en:223</urnl:rar> 
<urnl:sedName>SED_SSP2_SBE2</urnl:sedName> 
<urnl:order>10</urnl:order> 
<urnl:flags>u</urnl:flags> 
<urnl:svcs>E2U+sip</urnl:svcs> 
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«urnl:regx» 
<urnl:ere>” (.*)$</urnl:ere> 
<urnl:repl>sip:N16sbe2.ssp2.example.com</urnl:repl> 
</urnl:regx> 
</addObj> 


<addObj xsi:type="urnl:SedGrpType"> 
<urnl:rant>iana-en:222</urnl:rant> 
<urnl:rar>iana-en:223</urnl:rar> 
<urn1: sedGrpName>SED_GRP_SSP2_1</urnl:sedGrpName> 
<urnl:sedRecRef> 
<urnl:sedKey xsi:type="urn:ObjKeyType"> 
<rant>iana-en:222</rant> 
<name>SED_SSP2_SBE2</name> 
<type>SedRec</type> 
«/urnl:sedKey» 
«urnl:priority»100«/urnl:priority» 
«/urnl:sedRecRef» 
«urnl:dgName»DEST GRP SSP2 1«/urni:dgName» 
<urnl:isInSvc>true</urnl:isInSvc> 
<urnl:priority>10</urnl:priority> 
</addObj> 


<addObj xsi:type="urnl:SedGrpOfferType"> 
<urnl:rant>iana-en:222</urnl:rant> 
<urnl:rar>iana-en:223</urnl:rar> 
<urnl:sedGrpOfferKey xsi:type-"urn:SedGrpOfferKeyType"» 
<sedGrpKey xsi:type="urn:ObjKeyType"> 
<rant>iana-en:222</rant> 
<name>SED_GRP_SSP2_1</name> 
<type>SedGrp</type> 
</sedGrpKey> 
<offeredTo>iana-en:111</offeredTo> 
«/urnl:sedGrpOfferKey» 
<urnl:status>offered</urnl:status> 
<urnl:offerDateTime> 
2006-05-04T18:13:51.02 
</urnl:offerDateTime> 
</addObj> 


<delObj xsi:type="urn:PubldKeyType"> 
<rant>iana-en:222</rant> 

<number> 
<urnl:value>+12025556666</urnl:value> 
<urnl:type>TN</urnl:type> 

</number> 

«/delObj» 
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«delObj xsi:type="urn:ObjKeyType"> 
<rant>iana-en:222</rant> 
<name>SED_GRP_SSP2_Previous</name> 
<type>SedGrp</type> 

«/delObj» 


«rejectSedGrpOffer» 

«sedGrpKey» 
<rant>iana-en:226</rant> 
<name>SED_SSP4_SBE1_Offered</name> 
<type>SedGrp</type> 

</sedGrpKey> 

<offeredTo>iana-en:222</offeredTo> 

</rejectSedGrpOffer> 


</urn:spppBatchReguest> 
</soapenv:Body> 
</soapenv:Envelope> 


August 2016 


The Registry completes the reguest successfully and returns a 


favorable response. 


<?xml version="1.0" encoding-"UTF-8"?» 
«S:Envelope 


xmlns:S-"http://schemas.xmlsoap.org/soap/envelope/"» 


«S:Body» 
«ns3:spppBatchResponse 


xmlns:ns2="urn:ietf:params:xml:ns:sppf:base:1" 
xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> 


<serverTransId>tx_12354</serverTransId> 
<overallResult> 
<code>1000</code> 
<msg>Request Succeeded.</msg> 
</overallResult> 
«/ns3:spppBatchResponse» 
«/S:Body» 
«/S:Envelope» 
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11. 


11. 


Security Considerations 


The base security considerations of SPPP outlined in Section 9 of 
[RFC7877] also apply to SPPP over SOAP implementations. 
Additionally, the following must be considered: 


SPPP over SOAP is used to query and update session peering data and 
addresses, so the ability to access this protocol should be limited 
to users and systems that are authorized to query and update this 
data. Because this data is sent in both directions, it may not be 
sufficient for just the client or user to be authenticated with the 
server. The identity of the server should also be authenticated by 
the client, which is often accomplished using the TLS certificate 
exchange and validation described in [RFC2818]. 


1. Vulnerabilities 


Section 5 describes the use of HTTP and TLS as the underlying 
substrate protocols for SPPP over SOAP. These underlying protocols 
may have various vulnerabilities, and these may be inherited by SPPP 
over SOAP. SPPP over SOAP itself may have vulnerabilities because an 
authorization model is not explicitly specified in this document. 


During a TLS handshake, TLS servers can optionally request a 
certificate from a TLS client; that option is not a requirement for 


this protocol. This presents a denial-of-service risk in which 
unauthenticated clients can consume server CPU resources by creating 
TLS sessions. The risk is increased if the server supports client- 


initiated renegotiation. This risk can be mitigated by disabling 
client-initiated renegotiation on the server and by ensuring that 
other means (such as firewall access control lists) are used to 
restrict unauthenticated client access to servers. 


In conjunction with the above, it is important that SPPP over SOAP 
implementations implement an authorization model that considers the 
Source of each query or update request and determines whether it is 
reasonable to authorize that source to perform that specific query or 
update. 
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12. IANA Considerations 


This document uses URNs to describe XML Namespaces and XML Schemas. 
According to [RFC3688], IANA has performed the following URN 
assignment: 


URN: urn:ietf:params:xml:ns:sppf:soap:l 

Registrant Contact: IESG 

XML: See Section 9 of [RFC7878] 
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